HTTP Flashcards
Header: ‘Accept-Language’
The Accept-Language request HTTP header advertises which languages the client is able to understand, and which locale variant is preferred. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice with the Content-Language response header. Browsers set adequate values for this header according their user interface language.
This header is a hint to be used when the server has no way of determining the language via another way, like a specific URL, that is controlled by an explicit user decision. It is recommended that the server never overrides an explicit decision. The content of the Accept-Language is often out of the control of the user (like when traveling and using an Internet Cafe in a different country); the user may also want to visit a page in another language than the locale of their user interface.
If the server cannot serve any matching language, it can theoretically send back a 406 (Not Acceptable) error code. But, for a better user experience, this is rarely done and more common way is to ignore the Accept-Language header in this case.
Syntax
Accept-Language:
Accept-Language:
Accept-Language: *
// Multiple types, weighted with the quality value syntax: Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
Header: Accept
The Accept header lists the MIME types of media resources that the agent is willing to process. It is comma-separated lists of MIME types, each combined with a quality factor, a parameter indicating the relative degree of preference between the different MIME types.
The Accept header is defined by the browser, or any other user-agent, and can vary according to the context, like fetching an HTML page or an image, a video, or a script: It is different when fetching a document entered in the address bar or an element linked via an <img></img>, or element. Browsers are free to use the value of the header that they think is the most adequate; an exhaustive list of default values for common browsers is available.
Header: ‘Accept-Charset’
The Accept-Charset request HTTP header advertises which character set the client is able to understand. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice within the Content-Type response header. Browsers usually don’t set this header as the default value for each content type is usually correct and transmitting it would allow easier fingerprinting.
If the server cannot serve any matching character set, it can theoretically send back a 406 (Not Acceptable) error code. But, for a better user experience, this is rarely done and the more common way is to ignore the Accept-Charset header in this case.
Header: Vary
The Vary HTTP response header determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server. It is used by the server to indicate which headers it used when selecting a representation of a resource in a content negotiation algorithm.
The Vary header should be set on a 304 Not Modified response exactly like it would have been set on an equivalent 200 OK response.
Header type: Response header Forbidden header name: no Syntax: Vary: * Vary: , , ... Directives * Each request for a URL is supposed to be treated as a unique and uncacheable request. A better way to indicate this is to use Cache-Control: private, which is clearer to read and also signals that the object shouldn't be stored ever.
A comma-separated list of header names to take into account when deciding whether or not a cached response can be used.
Status Code:
100 Continue
This interim response indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished.
Status Code:
101 Switching Protocol
This code is sent in response to an Upgrade request header by the client, and indicates the protocol the server is switching too.
Status Code:
103 Processing
This code indicates that the server has received and is processing the request, but no response is available yet.
Status Code:
200 OK
The request has succeeded. The meaning of a success varies depending on the HTTP method:
GET: The resource has been fetched and is transmitted in the message body.
HEAD: The entity headers are in the message body.
POST: The resource describing the result of the action is transmitted in the message body.
TRACE: The message body contains the request message as received by the server
Status Code:
201 Created
The request has succeeded and a new resource has been created as a result of it. This is typically the response sent after a PUT request.
Status Code:
202 Accepted
The request has been received but not yet acted upon. It is non-committal, meaning that there is no way in HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing.
Status Code:
203 Non-Authoritative Information
This response code means returned meta-information set is not exact set as available from the origin server, but collected from a local or a third party copy. Except this condition, 200 OK response should be preferred instead of this response.
Status Code:
204 No Content
There is no content to send for this request, but the headers may be useful. The user-agent may update its cached headers for this resource with the new ones.
Status Code:
205 Reset Content
This response code is sent after accomplishing request to tell user agent reset document view which sent this request.
Status Code:
206 Partial Content
This response code is used because of range header sent by the client to separate download into multiple streams.
Status Code:
300 Multiple Choice
The request has more than one possible responses. User-agent or user should choose one of them. There is no standardized way to choose one of the responses.
