HTTP Conditional Request
*복습 자료라서 뻔한 내용은 생략
Summary.
1. HTTP has a concept of conditional requests, where the result, and even the success of a request, can be changed by comparing the affected resources with the value of a validator. Such requests can be useful to validate the content of a cache, and sparing a useless control, to verify the integrity of a document, like when resuming a download, or when preventing lost updates when uploading or modifying a document on the server
- for safe methods, like GET, which usually tries to fetch a document, the conditional request can be used to send back the document, if relevant only. Therefore, this spares bandwidth.
- for unsafe methods, like PUT, which usually uploads a document, the conditional request can be used to upload the document, only if the original it is based on is the same as that stored on the server
2. All conditional headers try to check if the resource stored on the server matches a specific version. To achieve this, the conditional requests need to indicate the version of the resource. As comparing the whole resource byte to byte is impracticable, and not always what is wanted, the request transmits a value describing the version. Such values are called validators, and are of two kinds:
- the date of last modification of the document, the last-modified date.
- an opaque string, uniquely identifying each version, called the entity tag, or the etag.
+ Comparing versions of the same resource is a bit tricky: depending on the context, there are two kinds of equality checks:
- Strong validation is used when byte to byte identity is expected, for example when resuming a download.
- Weak validation is used when the user-agent only needs to determine if the two resources have the same content. This is even if they are minor differences; like different ads, or a footer with a different dat
+ HTTP uses strong validation by default, and it specifies when weak validation can be used
+ Strong Validation: It is quite difficult to have a unique identifier for strong validation with Last-Modified. Often this is done using an ETag with the MD5 hash of the resource (or a derivative)
+ Weak validation differs from strong validation, as it considers two versions of the document as identical if the content is equivalent. For example, a page that would differ from another only by a different date in its footer, or different advertising, would be considered identical to the other with weak validation (Etag를 잘 정의해서?)
3. Conditional Headers
+ If-Match
+ Succeeds if the ETag of the distant resource is equal to one listed in this header. By default, unless the etag is prefixed with 'W/', it performs a strong validation.
+If-None-Match
+ Succeeds if the ETag of the distant resource is different to each listed in this header. By default, unless the etag is prefixed with 'W/', it performs a strong validation.
+If-Modified-Since
+ Succeeds if the Last-Modified date of the distant resource is more recent than the one given in this header.
+If-Unmodified-Since
+ Succeeds if the Last-Modified date of the distant resource is older or the same as the one given in this header.
+If-Range
+ Similar to If-Match, or If-Unmodified-Since, but can have only one single etag, or one date. If it fails, the range request fails, and instead of a 206 Partial Content response, a 200 OK is sent with the complete resource.
4. Use Cases
+ Cache update
+ Cache-Control 값도 잘 설정할 것
+ Besides the setting of the validators on the server side, this mechanism is transparent: all browsers manage a cache and send such conditional requests without any special work to be done by Web developers
+ Integrity of a partial download
+ A server supporting partial downloads broadcasts this by sending the Accept-Ranges header. Once this happens, the client can resume a download by sending a Ranges header with the missing ranges
+ there is one potential problem: if the downloaded resource has been modified between both downloads, the obtained ranges will correspond to two different versions of the resource, and the final document will be corrupted
+ makes use of If-Unmodified-Since and If-Match and the server returns an error if the precondition fails; the client then restarts the download from the beginning (Even if this method works, it adds an extra response/request exchange when the document has been changed. This impairs performance, and HTTP has a specific header to avoid this scenario: If-Range)
+ Avoiding the lost update problem with optimistic locking
+ Dealing with the first upload of a resource
+ by adding If-None-Match with the special value of '*', representing any etag. The request will succeed, only if the resource didn't exist before
+ If-None-Match will only work with HTTP/1.1 (and later) compliant servers. If unsure if the server will be compliant, you need first to issue a HEAD request to the resource to check this