Trail: HTTPRequestsandHeaderFields

Performance Testing : HTTPRequestsandHeaderFields

KnowledgeBase :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

HTTP Requests and Header Fields


Types of Requests
  1. Get: Means retrieve whatever data is identified by the URI, so where the URI refers to a data-producing process, or a script which can be run by such a process, it is this data which will be returned, and not the source text of the script or process
  2. Head: Is the same as GET but returns only HTTP headers and no document body.
  3. Checkout: Similar to GET but locks the object against update by other people. The lock may be broken by a higher authority or on timeout: in this case a future CHECKIN will fail.
  4. Showmethod: Returns a description (perhaps a form) for a given method when applied to the given object. The method name is specified in a For-Method: field. (TBS)
  5. Put: Specifies that the data in the body section is to be stored under the supplied URL. The URL must already exist. The new contents of the document are the data part of the request. Post and Reply should be used for creating new documents.
  6. Delete: Requests that the server delete the information corresponding to the given URL. After a successful DELETE method, the URL becomes invalid for any future methods.
  7. Post: Creates a new object linked to the specified object. The message-id field of the new object may be set by the client or else will be given by the server. A URL will be allocated by the server and returned to the client. The new document is the data part of the request. It is considered to be subordinate to the specified object, in the way that a file is subordinate to a directory containing it, or a news article is subordinate to a newsgroup to which it is posted.
  8. Link: Links an existing object to the specified object.
  9. Unlink: Removes link (or other meta-) information from an object.
  10. Checkin: Similar to PUT, but releases the lock set on the object. Fails if no lock has been set by CHECKOUT. Suggestion: phase out this (rcs-like) model in favor of the PUT (cvs-like, non-locking) model of code management.
  11. Textsearch: The object may be queried with a text string. The search form of the GET method is used to query the object.
  12. Spacejump: The object will accept a query whose terms are the coordinates of a point within the object. The method is implemented using GET with a derived URL.
  13. Search: Proposed only. The index (etc) identified by the URL is to be searched for something matching in some sense the enclosed message.

Types of Header Fields
  1. Accept: This header specifies the MIME types that the browser or other client can handle. For example, images in PNG format have some compression advantages over those in GIF, but only a few browsers support PNG. If you had images in both formats, a servlet could call request.getHeader ("Accept"), check for image/png, and if it finds it, use xxx.png filenames in all the IMG elements it generates. Otherwise it would just use xxx.gif.
  2. Accept-Charset: This header indicates the character sets (e.g., ISO-8859-1) the browser can use.
  3. Accept-Encoding: This header designates the types of encodings that the client knows how to handle. If it receives this header, the server is free to encode the page by using the format specified (usually to reduce transmission time), sending the Content-Encoding response header to indicate that it has done so. This encoding type is completely distinct from the MIME type of the actual document (as specified in the Content-Type response header), since this encoding is reversed before the browser decides what to do with the content. On the other hand, using an encoding the browser doesn't understand results in totally incomprehensible pages. Values of gzip or compress are the two standard possibilities
  4. Accept-Language: This header specifies the client's preferred languages. The value of the header should be one of the standard language codes such as en, en-us, da, etc. See RFC 1766 for details.
  5. Authorization: This header is used by clients to identify themselves when accessing password-protected Web pages.
  6. Cache-Control: This header can be used by the client to specify a number of options for how pages should be cached by proxy servers. The request header is usually ignored by servlets, but the Cache-Control response header can be valuable to indicate that a page is constantly changing and shouldn't be cached.
  7. Connection: This header tells whether or not the client can handle persistent HTTP connections. These let the client or other browser retrieve multiple files (e.g., an HTML file and several associated images) with a single socket connection, saving the overhead of negotiating several independent connections. With an HTTP 1.1 request, persistent connections are the default, and the client must specify a value of close for this header to use old-style connections. In HTTP 1.0, a value of keep-alive means that persistent connections should be used.
  8. Content-Length: This header is only applicable to POST requests and gives the size of the POST data in bytes.
  9. Content-Type: Although this header is usually used in responses from the server, it can also be part of client requests when the client attaches a document as the POST data or when making PUT requests.
  10. Cookie: This header is used to return cookies to servers that previously sent them to the browser. Technically, Cookie is not part of HTTP 1.1. It was originally a Netscape extension but is now very widely supported, including in both Netscape and Internet Explorer.
  11. Expect: This rarely used header lets the client tell the server what kinds of behaviors it expects. The one standard value for this header, 100-con-tinue, is sent by a browser that will be sending an attached document and wants to know if the server will accept it. The server should send a status code of either 100 (Continue) or 417 (Expectation Failed) in such a case.
  12. From: This header gives the e-mail address of the person responsible for the HTTP request. Browsers do not send this header, but Web spiders (robots) often set it as a courtesy to help identify the source of server overloading or repeated improper requests.
  13. Host: Browsers are required to specify this header, which indicates the host and port as given in the original URL. Due to request forwarding and machines that have multiple hostnames, it is quite possible that the server could not otherwise determine this information. This header is not new in HTTP 1.1, but in HTTP 1.0 it was optional, not required.
  14. If-Match: This rarely used header applies primarily to PUT requests. The client can supply a list of entity tags as returned by the ETag response header, and the operation is performed only if one of them matches.
  15. If-Modified-Since: This header indicates that the client wants the page only if it has been changed after the specified date. This option is very useful because it lets browsers cache documents and reload them over the network only when they've changed.
  16. If-None-Match: This header is like If-Match, except that the operation should be per-formed only if no entity tags match.
  17. If-Range: This rarely used header lets a client that has a partial copy of a document ask for either the parts it is missing (if unchanged) or an entire new document (if it has changed since a specified date).
  18. If-Unmodified-Since: This header is like If-Modified-Since in reverse, indicating that the operation should succeed only if the document is older than the specified date. Typically, If-Modified-Since is used for GET requests ("give me the document only if it is newer than my cached version"), whereas If-Unmodified-Since is used for PUT requests ("update this document only if nobody else has changed it since I generated it").
  19. Pragma: A Pragma header with a value of no-cache indicates that a servlet that is acting as a proxy should forward the request even if it has a local copy. The only standard value for this header is no-cache.
  20. Proxy-Authorization: This header lets clients identify themselves to proxies that require it.
  21. Range: This rarely used header lets a client that has a partial copy of a document ask for only the parts it is missing.
  22. Referer: This header indicates the URL of the referring Web page. For example, if you are at Web page 1 and click on a link to Web page 2, the URL of Web page 1 is included in the Referer header when the browser requests Web page 2. All major browsers set this header, so it is a useful way of tracking where requests came from. This capability is helpful for tracking advertisers who refer people to your site, for changing content slightly depending on the referring site, or simply for keeping track of where your traffic comes from. In the last case, most people simply rely on Web server log files, since the Referer is typically recorded there. Although it's useful, don't rely too heavily on the Referer header since it can be easily spoofed by a custom client. Finally, note that this header is Referer, not the expected Referrer, due to a spelling mistake by one of the original HTTP authors.
  23. Upgrade: The Upgrade header lets the browser or other client specify a communication protocol it prefers over HTTP 1.1. If the server also supports that protocol, both the client and the server can switch protocols.
  24. User-Agent: This header identifies the browser or other client making the request and can be used to return different content to different types of browsers. Most Internet Explorer versions list a "Mozilla" (Netscape) version first in their User-Agent line, with the real browser version listed parenthetically. This is done for compatibility with JavaScript, where the User-Agent header is sometimes used to determine which JavaScript features are supported.
  25. Via: This header is set by gateways and proxies to show the intermediate sites the request passed through.
  26. Warning: This rarely used catchall header lets clients warn about caching or con-tent transformation errors.
From http://solutions.rational.com/solutions/display.jsp solution id 123832806

See also http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html or http://www.faqs.org/rfcs/rfc2616

There are no comments on this page. [Add comment]

Page History :: 2006-01-27 19:26:35 XML :: Owner: Roland Stens :: Search:
Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by Wikka Wakka Wiki 1.1.6.0
Page was generated in 0.0212 seconds