Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

a. Explain how using the conditional GET method and web caching can improve the

ID: 3585730 • Letter: A

Question

a. Explain how using the conditional GET method and web caching can improve the response time for HTTP requests. b. To emphasize the importance of web caching, consider the following scenario: An institutional network runs over a LAN with RLAN = 100 Mbps, that has several hosts acting primarily as HTTP clients. The gateway router of the institution is connected to the ISP router, in the public Internet, by a DSL link with Race = 10 Mbps. The origin HTTP servers, also attached to the Internet, have web objects eg. HTMLJPG, MPEG files that are requested by the clients. Suppose that the average request size is Leg = 1 kilobits, the average object size is Robj = 1 megabits, and that the average request rate from the HTTP clients to the origin servers is = 10 req /s. Assume the average round-trip Internet delay is Tint = 1s. As a rough approximation, if the traffic intensity on a given link is p

Explanation / Answer

a)Answer:

A conditional GET is an HTTP GET request that may return an HTTP 304 response (instead of HTTP 200). An HTTP 304 response indicates that the resource has not been modified since the previous GET, and so the resource is not returned to the client in such a response. See RFC 7232 for details.

There are at least two (not completely independent) approaches to conditional GET:

In both cases, the value of a response header is used as the value of a subsequent request header. For example, note the Last-Modified and ETag headers in the response to this HEAD request for InCommon metadata:

$ MD_LOCATION=http://md.incommon.org/InCommon/InCommon-metadata.xml

$ /usr/bin/curl --silent --head $MD_LOCATION

HTTP/1.1 200 OK

Date: Tue, 30 Dec 2014 19:25:39 GMT

Server: Apache

Last-Modified: Mon, 29 Dec 2014 20:24:24 GMT

ETag: "110328-b28945-50b60a9050e00"

Accept-Ranges: bytes

Content-Length: 11700549

Connection: close

Content-Type: application/samlmetadata+xml

If we take the value of the Last-Modified header from the previous response as the value of the If-Modified-Since header in the following request, we receive a 304 response (and no content) from the server:

$ /usr/bin/curl --silent --head $MD_LOCATION

     --header 'If-Modified-Since: Mon, 29 Dec 2014 20:24:24 GMT'

HTTP/1.1 304 Not Modified

Date: Tue, 30 Dec 2014 19:26:20 GMT

Server: Apache

Connection: close

ETag: "110328-b28945-50b60a9050e00"

Similarly, if we take the value of the ETag header from the previous response as the value of the If-None-Match header in the following request, we again receive a 304 response:

$ /usr/bin/curl --silent --head $MD_LOCATION

     --header 'If-None-Match: "110328-b28945-50b60a9050e00"'

HTTP/1.1 304 Not Modified

Date: Tue, 30 Dec 2014 19:26:58 GMT

Server: Apache

Connection: close

ETag: "110328-b28945-50b60a9050e00"

The use of conditional GET has significant benefits, on both the client and the server (and the intervening network as well). On the InCommon metadata server, roughly 3/4 of all metadata requests result in HTTP 304. That translates into many thousands of metadata requests per day that conveniently avoid the unnecessary overhead of metadata refresh. For a file whose size is large and growing, that represents a significant cost savings.

Conditional GET has security benefits as well. Since requests that result in HTTP 304 are issued virtually without penalty, a client can request metadata more frequently than absolutely necessary. In the case of InCommon metadata, which is produced daily, hourly requests will result in just one HTTP 200 response in a typical 24-hour period. If, however, InCommon Operations signs metadata more than once per day (which happens on occasion), or more importantly, a key in metadata is compromised, necessitating an immediate production run, the fact that clients are attempting to refresh metadata hourly has significant potential benefit.

example:

The HTTP Protocol defines a caching mechanism, in which the proxy web-servers can cache pages, files, images etc. Since caching is in place, There is a method which the servers are asked to return the document, either the “cached” or “live” document.

This request of asking the server for a document considering a specific parameter is called a Conditional GET Request. In this request, a specific request header is sent If-Modified-Since. This header sends a RFC 2822 formatted date as the value. The proxy which is between the Server and the client checks the date, and the cached document, if the condition matches, A 304 Not Modified header is sent back to the client in the response.

So consider a document /sample.html on example.com. Consider the very first request of the Client, Since this is the first request, the client does not know about the modified time, etc…

Here goes the request header as follows…

GET /sample.html HTTP/1.1
Host: example.com

Now the response that comes from the server is the document with the response headers. The response headers would be…

HTTP/1.x 200 OK
Via: The-proxy-name
Content-Length: 32859
Expires: Tue, 27 Dec 2005 11:25:11 GMT
Date: Tue, 27 Dec 2005 05:25:11 GMT
Content-Type: text/html; charset=iso-8859-1
Server: Apache/1.3.33 (Unix) PHP/4.3.10
Cache-Control: max-age=21600
Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT
Etag: “4135cda4”

Lets check what these headers mean..

Once the Server responds, the client caches the document and stores it for the specified amount of time, In this case for 21600 seconds.

Next time when the user calls for the same document /sample.htmlwithin the specified cache time frame. The browser(client) will make a conditional get request, try to ask the server that if the document is modified after the specified time zone whose hashed value was the Etag value, ONLY THEN return a new document or else confirm that it is an old document.

So the request header would be as…

GET /sample.html HTTP/1.1
Host: example.com
If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT
If-None-Match: “4135cda4”

The header is self explanatory, it is asking for a new document which modified after Wed, 01 Sep 2004 13:24:52. The If-None-Match specifies that the client has mapped the document with that Entity value. RFC 2616 specifies that if If-None-Match is not accompanied with If-Modified-Since then the server must not send a 304 (Not Modified) header.

The response to the above request would be as.

HTTP/1.x 304 Not Modified
Via: The-proxy-server
Expires: Tue, 27 Dec 2005 11:25:19 GMT
Date: Tue, 27 Dec 2005 05:25:19 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.10
Keep-Alive: timeout=2, max=99
Etag: “4135cda4”
Cache-Control: max-age=21600

The server confirms the that the document is not modified and sends a 304 Not Modified header.

The client checks the 304 response header, and renders the document from the cache.

$ MD_LOCATION=http://md.incommon.org/InCommon/InCommon-metadata.xml

$ /usr/bin/curl --silent --head $MD_LOCATION

HTTP/1.1 200 OK

Date: Tue, 30 Dec 2014 19:25:39 GMT

Server: Apache

Last-Modified: Mon, 29 Dec 2014 20:24:24 GMT

ETag: "110328-b28945-50b60a9050e00"

Accept-Ranges: bytes

Content-Length: 11700549

Connection: close

Content-Type: application/samlmetadata+xml

Hire Me For All Your Tutoring Needs
Integrity-first tutoring: clear explanations, guidance, and feedback.
Drop an Email at
drjack9650@gmail.com
Chat Now And Get Quote