Http headers: Difference between revisions

From 탱이의 잡동사니
Jump to navigation Jump to search
 
(28 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Overview ==
== Overview ==
HTTP 헤더 관련 내용 정리
HTTP 헤더 관련 내용 정리
Line 6: Line 5:
원문은 이곳<ref>http://en.wikipedia.org/wiki/List_of_HTTP_header_fields</ref>에서 확인할 수 있다.
원문은 이곳<ref>http://en.wikipedia.org/wiki/List_of_HTTP_header_fields</ref>에서 확인할 수 있다.


== Request field ==
== Cache-Control ==
원문은 이곳<ref>http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html</ref>에서 확인할 수 있다.
* https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
 
전송되는 내용을 캐싱해 줄 것을 요청한다.
 
The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. Caching directives are unidirectional, meaning that a given directive in a request is not implying that the same directive is to be given in the response.
 
=== Syntax ===
'''Cache request directives'''
<pre>
Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached
</pre>
 
'''Cache response directives'''
<pre>
Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>
</pre>
 
'''Extension Cache-Control directives'''
: Extension ''Cache-Control'' directives are not part of the core HTTP caching standards document. Be sure to check the compatibility table for their support.
<pre>
Cache-Control: immutable
Cache-Control: stale-while-revalidate=<seconds>
Cache-Control: stale-if-error=<seconds>
</pre>
 
=== Directives ===
==== Cacheability ====
'''public'''
: Indicates that the reponse may be cached by any cache, even if the response would normally be non-cacheable(e.g. if the response does not contain a ''max-age'' directive or the ''Expires'' header).
 
== ETag ==
* https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag
 
The ETag HTTP response header is an identifier for a specific version of a resource. It lets caches be more efficient and save bandwidth, as a web server does not need to resend a full response if the content has not changed. Additionally, etags help prevent simultaneous updates of a resource from overwriting each other ("mid-air collisions").
 
If the resource at a given URL changes, a new Etag value must be generated. A comparison of them can determine whether two representations of a resource are the same. Etags are therefore similar to fingerprints, and might also be used for tracking purposes by some servers. They might also be set to persist indefinitely ba a tracking server.
 
=== Syntax ===
<pre>
ETag: W/"<etag_value>"
ETag: "<etag_value>"
</pre>
 
=== Directives ===
''W/''
: 'W/'(case-sensitive) indicates that a weak validator is used. Weak etags are easy to generate, but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult to generate efficiently. Weak ETag values of two representations of the same resources might be semantically equivalent, but not byte-for-byte identical. This means weak etags prevent caching when byte rage requests are used, but strong etags mean range requests can still be cached.
 
''<etag_value>''
: Entity tag uniquely representing the requested resource. They are a string of ASCII characters placed between  double quotes, like "675af34563dc-tr34". The method by which ETag values are generated is not specified. Often, a hash of the content, a hash of the last modification timestamp, or just a revision number is used.
 
=== Example ===
<pre>
$ curl -v http://wiki.pchero21.com/images/4/4c/Sip_info_dialog.png
*  Trying 108.61.223.180...
* TCP_NODELAY set
* Connected to wiki.pchero21.com (108.61.223.180) port 80 (#0)
> GET /images/4/4c/Sip_info_dialog.png HTTP/1.1
> Host: wiki.pchero21.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 09 Sep 2019 15:07:02 GMT
< Server: Apache/2.4.10 (Debian)
< Last-Modified: Sat, 06 Jun 2015 13:58:37 GMT
< ETag: "59fc-517d9ce1e7d40"
< Accept-Ranges: bytes
< Content-Length: 23036
< Content-Type: image/png
<
</pre>
 
== If-Modified-Since ==
* https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since
The  If-Modified-Since request HTTP header makes the request conditional: the server will send back the requested resource, with a 200 status, only if it has been last modified after the given date. If the request has not been modified since, the response will be a 304 without any body; the Lst-Modified response header of a previous request will contain the date of last modification. Unlike If-Unmodified-Since, If-Modified-Since can only be used with a GET and HEAD.
 
When used in combination with If-None-Match, it is ignored, unless the server doesn't support If-None-Match.
 
The most common use case is to update cached entity that has no associated ETag.
 
=== Syntax ===
<pre>
If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
</pre>
 
=== Example ===
<pre>
$ curl -v http://pchero21.com/wp-content/uploads/2015/02/IMG_20141223_000241.jpg -H 'If-Modified-Since: "Sat, 06 Jun 2015 13:53:59 GMT"'
*  Trying 108.61.223.180...
* TCP_NODELAY set
* Connected to pchero21.com (108.61.223.180) port 80 (#0)
> GET /wp-content/uploads/2015/02/IMG_20141223_000241.jpg HTTP/1.1
> Host: pchero21.com
> User-Agent: curl/7.54.0
> Accept: */*
> If-Modified-Since: "Sat, 06 Jun 2015 13:53:59 GMT"
>
< HTTP/1.1 304 Not Modified
< Date: Mon, 09 Sep 2019 09:51:10 GMT
< Server: Apache/2.4.10 (Debian)
< ETag: "3dc94-517d9bd8c8bc0"
<
* Connection #0 to host pchero21.com left intact
</pre>
 
== If-None-Match ==
* https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match
The If-None-Match HTTP request header makes the request conditional. For GET and HEAD method, the server will send back the requested resource, with a 200 status, only if it doesn't have an ETag matching the given ones. For other methods, the request will be processed only if the eventually existing resource's ETag doesn't match any of the values listed.
 
When the condition fails for GET and HEAD methods, then the server must return HTTP status code 304(Not Modified). For methods that apply server-side changes, the status code 412(Preconditioin Failed) is used. Note that the server generating a 304 response MUST generate any of the following header fileds that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
 
The comparison with the stored ETag uses the weak comparison algorithm, meaning two files are considered identical not only if they  are identical byte to byte, but if the content is equivalent. For example, two pages that would differ only by the date of generation in the footer would be considered as identical.
 
When used in combination with If-Modified-Since, If-None-Match has precedence (if the server supports it).


=== From ===
There are two common use cases.
: For GET and HEAD methods, to update a cached entity that has associated ETag.
: For other methods, and in particular for PUT, If-None-Match used with the * value can be used to save a file not known to exist, guaranteeing that another upload didn't happen before, losing the data of the previous put; this problem is a variation of the lost update problem.


In Internet mail format, this gives the name of the requesting user. This field may be used for logging purposes and an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsability for the method performed.
=== Syntax ===
<pre>
If-None-Match: "<etag_value>"
If-None-Match: "<etag_value>", "<etag_value>",
If-None-Match: *
</pre>


The Internet mail address in this field does not have to correspond to the internet host which issued the request. (For example, when a request is passed through a gateway, then the original issuer's address should be used).
=== Example ===
<pre>
$ curl -v http://pchero21.com/wp-content/uploads/2015/02/IMG_20141223_000241.jpg -H 'If-None-Match: "3dc94-517d9bd8c8bc0"'
*  Trying 108.61.223.180...
* TCP_NODELAY set
* Connected to pchero21.com (108.61.223.180) port 80 (#0)
> GET /wp-content/uploads/2015/02/IMG_20141223_000241.jpg HTTP/1.1
> Host: pchero21.com
> User-Agent: curl/7.54.0
> Accept: */*
> If-None-Match: "3dc94-517d9bd8c8bc0"
>
< HTTP/1.1 304 Not Modified
< Date: Mon, 09 Sep 2019 09:45:47 GMT
< Server: Apache/2.4.10 (Debian)
< ETag: "3dc94-517d9bd8c8bc0"
<
* Connection #0 to host pchero21.com left intact
</pre>


The mail address should, if possible, be a valid mail address, whether or not it is in fact an internet mail address or the internet mail representation of an address on some other mail system.
== Request field ==
원문은 이곳<ref>http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html</ref>에서 확인할 수 있다.


=== Accept ===
=== Accept ===
Line 88: Line 240:


Language coding TBS. (ISO standard xxxx.)
Language coding TBS. (ISO standard xxxx.)
=== User-Agent ===
The user agent string of the user agent
This line if present gives the software program used by the original client. This is for statistical purposes and the tracing of protocol violations. It should be included. The first white space delimited word must be the software product name, with an optional slash and version designator. Other products which form part of the user agent may be put as separate words.
<pre>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
</pre>
=== Connection ===
Control options for the current connection and list of hop-by-hop request fields.
<pre>
Connection: keep-alive
Connection: Upgrade
</pre>
=== Referer ===
This optional header field allows the client to specify, for the server's benefit, the address ( URI ) of the document (or element within the document) from which the URI in the request was obtained.
This allows a server to generate lists of back-links to documents, for interest, logging, etc. It allows bad links to be traced for maintenance.
If a partial URI is given, then it should be parsed relative to the URI of the object of the request.
Example:
              Referer: http://www.w3.org/hypertext/DataSources/Overview.html


=== Authorization ===
=== Authorization ===
Line 149: Line 274:
Format of this field is the same as for Date:.
Format of this field is the same as for Date:.


=== Pragma ===
=== Cache-Control ===
전송되는 내용을 캐싱해 줄 것을 요청한다.
 
The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. Caching directives are unidirectional, meaning that a given directive in a request is not implying that the same directive is to be given in the response.
 
Example
<pre>
Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached
</pre>
 
=== Connection ===
Control options for the current connection and list of hop-by-hop request fields.
<pre>
Connection: keep-alive
Connection: Upgrade
</pre>


Syntax is the same as for other multiple-value fields in HTTP, like the Accept: field, namely, a comma-separated list of entries, for which the optional parameters are separated by semicolons.
=== From ===


Pragma directives should be understood by servers to which they are relevant, e.g. a proxy server; currently only one pragma is defined:
In Internet mail format, this gives the name of the requesting user. This field may be used for logging purposes and an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsability for the method performed.


no-cache
The Internet mail address in this field does not have to correspond to the internet host which issued the request. (For example, when a request is passed through a gateway, then the original issuer's address should be used).
    When present the proxy should not return a document from the cache even though it has not expired, but it should always request the document from the actual server.


Pragmas should be passed through by proxies even though they might have significance to the proxy itself. This is necessary in cases when the request has to go through many proxies, and the pragma should affect all of them.
The mail address should, if possible, be a valid mail address, whether or not it is in fact an internet mail address or the internet mail representation of an address on some other mail system.


=== Host ===
=== Host ===
Line 167: Line 312:
Host: en.wikipedia.org
Host: en.wikipedia.org
</pre>
</pre>
=== Referer ===
This optional header field allows the client to specify, for the server's benefit, the address ( URI ) of the document (or element within the document) from which the URI in the request was obtained.
This allows a server to generate lists of back-links to documents, for interest, logging, etc. It allows bad links to be traced for maintenance.
If a partial URI is given, then it should be parsed relative to the URI of the object of the request.
Example:
              Referer: http://www.w3.org/hypertext/DataSources/Overview.html
=== Pragma ===
Syntax is the same as for other multiple-value fields in HTTP, like the Accept: field, namely, a comma-separated list of entries, for which the optional parameters are separated by semicolons.
Pragma directives should be understood by servers to which they are relevant, e.g. a proxy server; currently only one pragma is defined:
no-cache
    When present the proxy should not return a document from the cache even though it has not expired, but it should always request the document from the actual server.
Pragmas should be passed through by proxies even though they might have significance to the proxy itself. This is necessary in cases when the request has to go through many proxies, and the pragma should affect all of them.


=== Transfer-Encoding ===
=== Transfer-Encoding ===
Line 179: Line 346:
x-compress      Deprecated (alias for compress) [RFC7230] Section 4.2.1
x-compress      Deprecated (alias for compress) [RFC7230] Section 4.2.1
x-gzip          Deprecated (alias for gzip) [RFC7230] Section 4.2.3
x-gzip          Deprecated (alias for gzip) [RFC7230] Section 4.2.3
</pre>
=== User-Agent ===
The user agent string of the user agent
This line if present gives the software program used by the original client. This is for statistical purposes and the tracing of protocol violations. It should be included. The first white space delimited word must be the software product name, with an optional slash and version designator. Other products which form part of the user agent may be put as separate words.
<pre>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
</pre>
</pre>


Line 184: Line 360:
<references />
<references />


[[category:etc]]
[[category:http]]

Latest revision as of 15:09, 9 September 2019

Overview

HTTP 헤더 관련 내용 정리

Header list

원문은 이곳<ref>http://en.wikipedia.org/wiki/List_of_HTTP_header_fields</ref>에서 확인할 수 있다.

Cache-Control

전송되는 내용을 캐싱해 줄 것을 요청한다.

The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. Caching directives are unidirectional, meaning that a given directive in a request is not implying that the same directive is to be given in the response.

Syntax

Cache request directives

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache 
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

Cache response directives

Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>

Extension Cache-Control directives

Extension Cache-Control directives are not part of the core HTTP caching standards document. Be sure to check the compatibility table for their support.
Cache-Control: immutable 
Cache-Control: stale-while-revalidate=<seconds>
Cache-Control: stale-if-error=<seconds>

Directives

Cacheability

public

Indicates that the reponse may be cached by any cache, even if the response would normally be non-cacheable(e.g. if the response does not contain a max-age directive or the Expires header).

ETag

The ETag HTTP response header is an identifier for a specific version of a resource. It lets caches be more efficient and save bandwidth, as a web server does not need to resend a full response if the content has not changed. Additionally, etags help prevent simultaneous updates of a resource from overwriting each other ("mid-air collisions").

If the resource at a given URL changes, a new Etag value must be generated. A comparison of them can determine whether two representations of a resource are the same. Etags are therefore similar to fingerprints, and might also be used for tracking purposes by some servers. They might also be set to persist indefinitely ba a tracking server.

Syntax

ETag: W/"<etag_value>"
ETag: "<etag_value>"

Directives

W/

'W/'(case-sensitive) indicates that a weak validator is used. Weak etags are easy to generate, but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult to generate efficiently. Weak ETag values of two representations of the same resources might be semantically equivalent, but not byte-for-byte identical. This means weak etags prevent caching when byte rage requests are used, but strong etags mean range requests can still be cached.

<etag_value>

Entity tag uniquely representing the requested resource. They are a string of ASCII characters placed between double quotes, like "675af34563dc-tr34". The method by which ETag values are generated is not specified. Often, a hash of the content, a hash of the last modification timestamp, or just a revision number is used.

Example

$ curl -v http://wiki.pchero21.com/images/4/4c/Sip_info_dialog.png
*   Trying 108.61.223.180...
* TCP_NODELAY set
* Connected to wiki.pchero21.com (108.61.223.180) port 80 (#0)
> GET /images/4/4c/Sip_info_dialog.png HTTP/1.1
> Host: wiki.pchero21.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 09 Sep 2019 15:07:02 GMT
< Server: Apache/2.4.10 (Debian)
< Last-Modified: Sat, 06 Jun 2015 13:58:37 GMT
< ETag: "59fc-517d9ce1e7d40"
< Accept-Ranges: bytes
< Content-Length: 23036
< Content-Type: image/png
<

If-Modified-Since

The If-Modified-Since request HTTP header makes the request conditional: the server will send back the requested resource, with a 200 status, only if it has been last modified after the given date. If the request has not been modified since, the response will be a 304 without any body; the Lst-Modified response header of a previous request will contain the date of last modification. Unlike If-Unmodified-Since, If-Modified-Since can only be used with a GET and HEAD.

When used in combination with If-None-Match, it is ignored, unless the server doesn't support If-None-Match.

The most common use case is to update cached entity that has no associated ETag.

Syntax

If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

Example

$ curl -v http://pchero21.com/wp-content/uploads/2015/02/IMG_20141223_000241.jpg -H 'If-Modified-Since: "Sat, 06 Jun 2015 13:53:59 GMT"'
*   Trying 108.61.223.180...
* TCP_NODELAY set
* Connected to pchero21.com (108.61.223.180) port 80 (#0)
> GET /wp-content/uploads/2015/02/IMG_20141223_000241.jpg HTTP/1.1
> Host: pchero21.com
> User-Agent: curl/7.54.0
> Accept: */*
> If-Modified-Since: "Sat, 06 Jun 2015 13:53:59 GMT"
>
< HTTP/1.1 304 Not Modified
< Date: Mon, 09 Sep 2019 09:51:10 GMT
< Server: Apache/2.4.10 (Debian)
< ETag: "3dc94-517d9bd8c8bc0"
<
* Connection #0 to host pchero21.com left intact

If-None-Match

The If-None-Match HTTP request header makes the request conditional. For GET and HEAD method, the server will send back the requested resource, with a 200 status, only if it doesn't have an ETag matching the given ones. For other methods, the request will be processed only if the eventually existing resource's ETag doesn't match any of the values listed.

When the condition fails for GET and HEAD methods, then the server must return HTTP status code 304(Not Modified). For methods that apply server-side changes, the status code 412(Preconditioin Failed) is used. Note that the server generating a 304 response MUST generate any of the following header fileds that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

The comparison with the stored ETag uses the weak comparison algorithm, meaning two files are considered identical not only if they are identical byte to byte, but if the content is equivalent. For example, two pages that would differ only by the date of generation in the footer would be considered as identical.

When used in combination with If-Modified-Since, If-None-Match has precedence (if the server supports it).

There are two common use cases.

For GET and HEAD methods, to update a cached entity that has associated ETag.
For other methods, and in particular for PUT, If-None-Match used with the * value can be used to save a file not known to exist, guaranteeing that another upload didn't happen before, losing the data of the previous put; this problem is a variation of the lost update problem.

Syntax

If-None-Match: "<etag_value>"
If-None-Match: "<etag_value>", "<etag_value>", …
If-None-Match: *

Example

$ curl -v http://pchero21.com/wp-content/uploads/2015/02/IMG_20141223_000241.jpg -H 'If-None-Match: "3dc94-517d9bd8c8bc0"'
*   Trying 108.61.223.180...
* TCP_NODELAY set
* Connected to pchero21.com (108.61.223.180) port 80 (#0)
> GET /wp-content/uploads/2015/02/IMG_20141223_000241.jpg HTTP/1.1
> Host: pchero21.com
> User-Agent: curl/7.54.0
> Accept: */*
> If-None-Match: "3dc94-517d9bd8c8bc0"
>
< HTTP/1.1 304 Not Modified
< Date: Mon, 09 Sep 2019 09:45:47 GMT
< Server: Apache/2.4.10 (Debian)
< ETag: "3dc94-517d9bd8c8bc0"
<
* Connection #0 to host pchero21.com left intact

Request field

원문은 이곳<ref>http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html</ref>에서 확인할 수 있다.

Accept

This field contains a semicolon-separated list of representation schemes ( Content-Type metainformation values) which will be accepted in the response to this request.

The set given may of course vary from request to request from the same user.

This field may be wrapped onto several lines according to RCFC822, and also more than one occurence of the field is allowed with the signifiance being the same as if all the entries has been in one field. The format of each entry in the list is (/ meaning "or")

       <field>  =    Accept: <entry> *[ , <entry> ]
       <entry>  =    <content type> *[ ; <param> ]
       <param>  =    <attr> = <float>
       <attr>   =    q / mxs / mxb
       <float>  =    <ANSI-C floating point text represntation>

See the appendix on the negotiation algorithm as a function and penalty model. Note that a semicolon has a higher precedence than a comma in this syntax, to conform to MIME use.

If no Accept: field is present, then it is assumed that text/plain and text/html are accepted. Example

               Accept: text/plain, text/html
               Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c

Wildcards

In order to save time, and also allow clients to receive content types of which they may not be aware, an asterisk "*" may be used in place of either the second half of the content-type value, or both halves. This only applies to the Accept: filed, and not to the content-type field of course. Example

                       Accept:  *.*, q=0.1
                       Accept:  audio/*, q=0.2
                       Accept:  audio/basic q=1

may be interpreted as "if you have basic audio, send it; otherwise send me some other audio, or failing that, just give me what you've got." Type parameters

Parameters on the content type are extremely useful for describing resolutions, colour depths, etc. They will allow a client to specify in the Accept: field the resolution of its device. This may allow the server to economise greatly on transmission time by reducing the resultion of an image, for example, and enable a more appropriate custom-designed black and white image to be selected rathther than giving the client a color image to convert into monochrome.

These parameters are to be specified when types are registered.. @@ TBS.

Sugestions include the following. Please feed back any references to existing improved abreviations for these:

dpi

   dots per inch: pixels per inch [cm?!]

pxmax

   maximum width in pixels (image or video)

pymax

   maximum height in pixels

bits

   bits per sample (sound) or pixels (graphics)

mchrome

   greyscale or black and white (no value)

sps

   samples (sound) or frames (video) per second

length

   total size of object in bytes [bits?]

Accept-Encoding:

Similar to Accept, but lists the Content-Encoding types which are acceptable in the response.

       <field>  =    Accept-Encoding: <entry> *[ , <entry> ]
       <entry>  =    <content transfer encoding> *[ , <param> ]

Example

               Accept-Encoding: x-compress; x-zip

Accept-Language

Similar to Accept, but lists the Language values which are preferable in the response. A response in an unspecifies language is not illegal. See also: Language .

Language coding TBS. (ISO standard xxxx.)

Authorization

If this line is present it contains authorization information. The format is To Be Specified (TBS). The format of this field is in extensible form. The first word is a specification of the authorisation system in use.

Basic

Specification for current one implemented by AL Sep 1993. PGP/PEM Encryption

People at NCSA are designing a PGP/PEM based protection system.

User/Password scheme

               Authorization:  user  fred:mypassword

The scheme name is "user". The second word is a user name (typically derived from a USER environment variable or prompted for), with an optional password separated by a colon (as in the URL syntax for FTP). Without a password, this povides very low level security. With the password, it provides a low-level security as used by unmodified FTP, Telnet, etc. Kerberos

               Authorization:  kerberos  kerberosauthenticationsparameters

The format of the kerberosauthenticationsparameters is to be specified. ChargeTo:

This line if present contains account information for the costs of the application of the method requested. The format is TBS. The format of this field must be in extensible form. The first word starts with a specification of the namespace in which the account is . (This is similar to extensible URL definition.) No namespaces are currently defined. Namespaces will be registered with the registration authority .

The format of the rest of the line is a function of the charging system, but it is recommended that this include a maximum cost whose payment is authorized by the client for this transaction, and a cost unit.

If-Modified-Since: date

This request header is used with GET method to make it conditional: if the requested document has not changed since the time specified in this field the document will not be sent, but instead a Not Modified 304 reply.

Format of this field is the same as for Date:.

Cache-Control

전송되는 내용을 캐싱해 줄 것을 요청한다.

The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. Caching directives are unidirectional, meaning that a given directive in a request is not implying that the same directive is to be given in the response.

Example

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache 
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

Connection

Control options for the current connection and list of hop-by-hop request fields.

Connection: keep-alive
Connection: Upgrade

From

In Internet mail format, this gives the name of the requesting user. This field may be used for logging purposes and an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsability for the method performed.

The Internet mail address in this field does not have to correspond to the internet host which issued the request. (For example, when a request is passed through a gateway, then the original issuer's address should be used).

The mail address should, if possible, be a valid mail address, whether or not it is in fact an internet mail address or the internet mail representation of an address on some other mail system.

Host

호스트의 이름과 URI의 PORT 번호를 지정한다. 클라이언트는 HTTP 1.1 에 반드시 이 정보를 공급해야 하는데, 이는 여러 개의 호스트명이 갖는 애매한 URL을 쉽게 구분하는데 도움이 된다. 서버의 도메인 이름(가상 호스팅을 위한..)과 TCP 포트 번호를 지정한다. HTTP/1.1 부터는 반드시 설정해야 한다.

Host: en.wikipedia.org:80
Host: en.wikipedia.org

Referer

This optional header field allows the client to specify, for the server's benefit, the address ( URI ) of the document (or element within the document) from which the URI in the request was obtained.

This allows a server to generate lists of back-links to documents, for interest, logging, etc. It allows bad links to be traced for maintenance.

If a partial URI is given, then it should be parsed relative to the URI of the object of the request. Example:

              Referer: http://www.w3.org/hypertext/DataSources/Overview.html

Pragma

Syntax is the same as for other multiple-value fields in HTTP, like the Accept: field, namely, a comma-separated list of entries, for which the optional parameters are separated by semicolons.

Pragma directives should be understood by servers to which they are relevant, e.g. a proxy server; currently only one pragma is defined:

no-cache

   When present the proxy should not return a document from the cache even though it has not expired, but it should always request the document from the actual server.

Pragmas should be passed through by proxies even though they might have significance to the proxy itself. This is necessary in cases when the request has to go through many proxies, and the pragma should affect all of them.

Transfer-Encoding

전송 인코딩 방식을 정의한다.

chunked         Transfer in a series of chunks [RFC7230] Section 4.1
compress        UNIX "compress" data format [Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.] [RFC7230] Section 4.2.1
deflate         "deflate" compressed data ([RFC1951]) inside the "zlib" data format ([RFC1950]) [RFC7230] Section 4.2.2
gzip            GZIP file format [RFC1952] [RFC7230] Section 4.2.3
identity 	(withdrawn in errata to [RFC2616]) [RFC2616] Section 3.6
x-compress      Deprecated (alias for compress) [RFC7230] Section 4.2.1
x-gzip          Deprecated (alias for gzip) [RFC7230] Section 4.2.3

User-Agent

The user agent string of the user agent

This line if present gives the software program used by the original client. This is for statistical purposes and the tracing of protocol violations. It should be included. The first white space delimited word must be the software product name, with an optional slash and version designator. Other products which form part of the user agent may be put as separate words.

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0

References

<references />