Created
January 13, 2014 21:31
-
-
Save rubenclopez/8408560 to your computer and use it in GitHub Desktop.
Response Headers
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Response Headers | |
---------------- | |
Response headers from the server give the client metadata about the resource being returned. Often, the response headers have matching corollaries in the request head- ers. Here is a list of response headers that you will most often be concerned with: | |
• Age: 30—This gives the time the resource has been in proxy cache, in seconds. | |
• Allow: GET, HEAD, PUT, DELETE—This lists the HTTP methods allowed on the resource. You saw this earlier, in the response to an OPTIONS request. | |
• Cache-Control: max-age=120—This header allows either the client or server more control over caching than the default mechanisms. These commands are intended for proxy caches that lie between the client and server. Chapter 8, “Load Balancing and Caching,” covers this in greater detail. | |
• Content-Encoding: gzip—This tells the client the encoding of the response. It is used for compression and gzip. | |
• Content-Length: 234—This gives the length of the response body, in bytes. | |
• Content-Type: application/json; charset=utf-8—This tells the client the MIME type of the response. This should match up with one of the types in the Accept header from the request. | |
• ETag: sdlkf234—The ETag gives a unique identifier of some sort for the resource. This identifier should match up with the version of the resource in some way. This could be an ID combined with a last_updated field or a hash of the 2 or some other value. This is used for caching purposes and matches with the If-None-Match request header. | |
• Expires: Wed, 01 Jul 2009 09:02:12 GMT—This tells the client or a proxy cache when a response should be considered stale. Either of these can verify whether the resource is up-to-date for a later request. | |
• Last-Modified: Wed, 01 Jul 2009 09:03:45 GMT—This is another caching mechanism. This matches up with the client-side header If-Modified-Since. Thus, with later requests for the same resource, the client can use the Last-Modified value for If-Modified-Since. | |
• Set-Cookie: user_id=paul—This sets the client-side cookie. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment