Some of us know a lot about what happen when we write URL in our browser and hit enter or when an app connect to a web service or API to get data or perform an operation, but let us discuss exactly what is going on between the browser or any client and the URL or any server resource like HTML page, files, or web service … etc. As many knows HTTP sort for Hypertext Transfers Protocol so every thing happen is written as text on this dialog between the client and the server but what is exactly this message is and what is the server replay that what we will try to clarify.
First let us discuss the client which may be web browser, app, or even an web debugging tools like fiddler, Post Man, SOAP UI. which I think we need to talk about after HTTP.
Client Message or HTTP Request, in a happy world the request between client and server simply done by sending the request with a certain structure (we will discuss it in details) to the server and wait for the server response, but this request can go throw a long way by passing to proxy, gateway, and/or tunnel. In sort, A proxy is a forwarding agent, receiving requests for a URL in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URL. A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server’s protocol. A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages.
2- Request header fields list, all header fields are optional except the host field. and the field structure is [Field Name] + [Colon] + [Field Value] + [Carriage return] + [Line feed]
ex: Host: tecgang.wordpress.com
3-Empty Line [Carriage return] + [Line feed] in order to split between request header and request body
4-[Optional] Request body, which can be anything, binary file, text, JSON data or any data you want to send it to the server
HTTP Request methods are:
GET: The GET method requests a representation of the specified resource. for example to get an image or html file.
HEAD: The HEAD method asks for a response identical to that of a GET request, but without the response body. for example if you want to get a file but you want to know the file length first then you request a HEAD. (Useful for retrieving meta-information)
POST: Used to ask the server to accept the entity enclosed in the request as a new entity of the resource identified by the URL.
PUT: Used to ask the server to accept the entity enclosed in the request to store an entity of the resource identified by the URL. if it not exists its create new one or update existing one.
DELETE: The DELETE method deletes the specified resource.
TRACE: The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.
OPTIONS: The OPTIONS method returns the HTTP methods that the server supports for the specified URL.
CONNECT: The client asks an HTTP Proxy server to tunnel the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client.
PATCH: The PATCH method update partial resources.
HTTP Response message structure (Header and body):
1- Status Code and message [HTTP Version] + [Status Code] + [Message] + [Carriage return] + [Line feed]
ex: HTTP/1.1 200 OK
2- Response header fields, all header fields are optional and the field structure is [Field Name] + [Colon] + [Field Value] + [Carriage return] + [Line feed]
ex: Content-Type: application/pdf
3- Empty Line [Carriage return] + [Line feed] in order to split between response header and response body
4-[Optional] Request body, which can be anything, binary file, text, JSON data or any data send by the server
Adding application insights to an existing Azure Application
Create a new application insights instance and associate to an existing app service
Select New resource
Look for “application insights”
Give your new instance a name
Give same name as app service to configure with application insights for ease of use
Wait for the instance to be deployed successfully and browse to it
Copy the instrumentation key (of iKey)
Now browse to the related app service and open the application settings
Add an application setting called ‘iKey’ and paste the instrumentation key copied previously
Save and restart the service (although when you save app settings the app service restarts). Allow for a few minutes for data to be collected.
Smoke tests
Logs: It is also possible to check the logs for confirmation that the new settings were taken into account.
In the Logging Framework logs: Ordering by descending EventDateTime, you should be able to find a couple of entries showing a restart of the application and that setting being applied
Message should show:
Note: The same should be added to the diagnostic logs should they be enabled
Editor: Confirm the default value does not exist anymore
Browse to the App Service Editor in your app service settings and click Go
Select ApplicationInsights.config and scroll to the bottom. The default value for the instrumentation key is commented out.
Other
It is possible that if you created the application service with an associated application insights instance, it would give you the option to enable application insights. But this document assumes that application insights is added after the creation of the related application service