[转]Quick reference to Internet message/HTTP headers
原文：
http://www.cs.tut.fi/~jkorpela/headers.html
http://www.cs.tut.fi/~jkorpela/http.html
Quick reference to Internet message headers
The following table lists Internet message header fields which have been defined in RFCs or actually used or both, in E-mail messages, Usenet messages, or other contexts. For each header, its name, a short description, and some reference is given; the reference tries to point to a document where the meaning of the header is specified or described. In several cases, the description is just an educated (?) guess. The use of the word nonstandard here typically means just lack of more specific information; it does not imply that other headers would necessarily be standard. This is a descriptive document, aimed at helping to find information in official and unofficial sources. This document does not cover HTTP headers; see a separate Quick reference to HTTP headers.
The alphabetic order is by words, counting a hyphen as word separator, so e.g. Mail-System-Version appears before Mailer.
| Header field name | Description | References or comments |
|---|---|---|
| Abuse-Reports-To | E-mail address for reporting abuse | Inserted by some news servers |
| Also-Control | Usenet control message and a normal article at the same time | "son-of-RFC1036": 6.15 |
| Alternate-Recipient | Controls whether the message may be forwarded to alternate recipients | RFC 2156 |
| Apparently-To | Recipients derived (by Sendmail) from message envelope when there is no Toheader |
nonstandard, discouraged, mentioned in RFC 1211 |
| Approved | Moderator of the Usenet newsgroup, or marks certain control messages | RFC 1036: 2.2.11 |
| Approved-By | Moderator of a mailing list, who approved the message | Used by some mailing list expansion systems |
| Article-Names | Reference to specially important articles for a particular Usenet newsgroup | "son-of-RFC1036": 6.17 |
| Article-Updates | Similar toSupersedes but does not cause the referenced article to be physically deleted |
"son-of-RFC1036": 6.18 |
| Autoforwarded | Has been automatically forwarded | RFC 2156 |
| Auto-Forwarded | Misspelling ofAutoforwarded |
Appears in some documents; perhaps not actually used |
| bcc | Recipient(s) not to be disclosed to other recipients ("blind carbon copy") | RFC 822: 4.5.3; RFC 1123: 5.2.15-16, 5.3.7; |
| Cache-Post-Path | ?? | Seems to appear in conjunction with X-Cache |
| cc | Secondary, informational recipient(s) | RFC 822: 4.5.2; RFC 1123: 5.2.15-16, 5.3.7; |
| Comments | Text comments added to the message | RFC 822: 4.7.2 |
| Content-Alias | Used in addition toContent-Location if this content part can be retrieved through more than one URI |
Work in progress |
| Content-Alternative | Information on where an alternative variant of this document might be found | draft-ietf-fax-content-negotiation-03.txt: 4 |
| Content-Base | Base to be used for resolving relative URIs within this content part | RFC 2110 |
| Content-Class | Type information of the content in some class hierarchy | Nonstandard |
| Content-Conversion | Whether the body may be converted from a charset to another | Nonstandard variant ofConversion |
| Content-Description | Description of a particular body part of a message | RFC 2045: 8 |
| Content-Disposition | Whether MIME body part is to be shown inline or as an attachment; may also suggest a file name | RFC 1806, RFC 2183 |
| Content-Features | More detailed information about the Content-Type |
Nonstandard |
| Content-ID | Unique ID of one body part of the content of a message | RFC 2045: 7 |
| Content-Identifier | A text string which identifies the content of a message | RFC 2156 |
| Content-Language | Code for natural language used in the message | RFC 1766: 3 |
| Content-Length | Size in bytes of the message text | Nonstandard,discouraged |
| Content-Location | URI with which the content of this content part might be retrievable | RFC 2110 |
| Content-MD5 | Checksum of content | RFC 1864 |
| Content-Return | Whether the content of a message is to be returned with non-delivery notifications | RFC 2156 |
| Content-SGML-Entity | Information about the SGML entity declaration corresponding to the body | Nonstandard |
| Content-Transfer-Encoding | Coding method used in a MIME message body | RFC 2045: 6; |
| Content-Type | Data type and format of content | RFC 1049 (historic);RFC 1123: 5.2.13; RFC 2045: 5; RFC 1766: 4.1 |
| Control | On Usenet, indicates a control message | RFC 1036: 2.1.6 |
| Conversion | Whether the body may be converted from a charset to another | RFC 2156 |
| Conversion-With-Loss | Whether the body may be converted from a charset to another if information will be lost | RFC 2156 |
| Date | The time when the message was written (or submitted) | RFC 822: 5.1; RFC 1123:5.2.14; RFC 1036: 2.1.2 |
| Delivered-To | Used for loop detection | Nonstandard |
| Delivery-Date | The time when a message was delivered to its recipient | RFC 2156 |
| Discarded-X400-IPMS-Extensions | X.400 IPM extensions which could not be mapped to Internet mail format | RFC 2156 |
| Discarded-X400-MTS-Extensions | X.400 MTS extensions which could not be mapped to Internet mail format | RFC 2156 |
| Disclose-Recipients | Controls whether recipients are to be told the names of other recipients | RFC 2156 |
| Disposition-Notification-Options | Options for notifications to be sent when the message is received | RFC 2298 |
| Disposition-Notification-To | Requests for notification when the message is received, and specifies the address for them | RFC 2298 |
| Distribution | Limitation on where the Usenet article can be distributed | RFC 1036: 2.2.7 |
| DL-Expansion-History-Indication | Trace of distribution lists passed | RFC 2156 |
| Encoding | Mixed usage: content type encoding, length, or boundary information | RFC 1154 (obsolete),RFC 1505 |
| Errors-To | Address to which notifications are to be sent and a request to get delivery notifications | nonstandard, discouraged |
| Envelope-ID | ? | Appears in E-mail and Usenet messages, seems to relate to relaying |
| Expires | Suggested expiration time | RFC 1036: 2.2.4 |
| Expiry-Date | Time at which a message loses its validity | RFC 2156 |
| Fax | Fax number of the originator | nonstandard |
| Fcc | Name of file in which a copy of the message is stored | Nonstandard |
| Followup-To | Usenet group(s) to which followups to the article should be sent | RFC 1036: 2.2.3 |
| For-Approval | Primary recipients, who are requested to approve the information in this message or its attachments | nonstandard |
| For-Comment | Primary recipients, who are requested to comment on the information in this message or its attachments | nonstandard |
| For-Handling | Primary recipients, who are requested to handle the information in this message or its attachments | nonstandard |
| From | Author(s) or person(s) taking responsibility for the message | 4.4.1; RFC 1123:5.2.15-16, 5.3.7; RFC 1036: 2.1.1 |
| Generate-Delivery-Report | Whether a delivery report is wanted at successful delivery | RFC 2156 |
| Importance | A hint from the originator to the recipients about how important a message is | RFC 2156; RFC 2421 |
| In-Reply-To | Reference to message which this message is a reply to | RFC 822: 4.6.2 |
| Incomplete-Copy | Body parts are missing | RFC 2156 |
| Injector-Info | Information about article's injection to Usenet | Inserted by Mailgate |
| Keywords | keywords to be used as an aid in determining if the message is interesting to the reader | RFC 1036: 2.2.9 |
| Language | Code for natural language used in the message | RFC 2156 |
| Lines | Number of lines in the body of the message | RFC 1036: 2.2.12 |
| List-Archive | URL to use to browse the archives of the mailing list | RFC 2369 |
| List-Digest | URL to use to subscribe to the digest version of the mailing list | Nonstandard |
| List-ID | URN of the the mailing list expander | Nonstandard, considered for inclusion in the protocol defined in RFC 2369 |
| List-Owner | URL to use to send E-mail to the owner of the mailing list | RFC 2369 |
| List-Post | URL to use to post to the mailing list | RFC 2369 |
| List-Software | Information about the software uses in the mailing list expander | Nonstandard, considered for inclusion in the protocol defined in RFC 2369 |
| List-Subscribe | URL to use to subscribe to the mailing list | RFC 2369 |
| List-Unsubscribe | URL to use to unsubscribe the mailing list | RFC 2369 |
| List-URL | URL for various information about the mailing list | Nonstandard |
| Mail-Copies-To | Special address for copies of posted followups | Mail-Copies-To Draft |
| Mail-Reply-Requested-By | Address to which notifications are to be sent and a request to get delivery notifications | nonstandard, discouraged |
| Mail-System-Version | client software used by the originator | nonstandard |
| Mailer | client software used by the originator | nonstandard |
| Mailing-List | Information about mailing list | Nonstandard, cf. toList-something headers |
| Message-ID | Unique ID for the message | RFC 822: 4.6.1; RFC 1036: 2.1.5 |
| Message-Type | Indicates that this is a delivery report gatewayed from X.400 | RFC 2156 |
| MIME-Version | specifies the version of MIME that the message format complies with | RFC 2045: 4 |
| Newsgroups | Usenet group(s) to which the article was posted | nonstandard and controversial for use in E-mail |
| NNTP-Posting-Date | time of posting to Usenet | appears in Usenet messages |
| NNTP-Posting-Host | host that posted the article to Usenet | appears in Usenet messages; contains name and/or IP address |
| NNTP-Posting-Time | time of posting to Usenet | appears in Usenet messages, variant of the more common NNTP-Posting-Date |
| NNTP-Proxy-Relay | Host that relayed the message to Usenet | Seems to appear in conjunction with NNTP-Posting-Host |
| Obsoletes | Reference to previous message being corrected and replaced | RFC 2156 |
| Old-Date | ? | Nonstandard, used by some mailing list software |
| Old-X-Envelope-From | ? | Nonstandard, used by some mailing list software |
| Old-X-Envelope-To | ? | Nonstandard, used by some mailing list software |
| Organisation | (MisspelledOrganization) |
Nonstandard |
| Organization | The organization to which the sender belongs, or to which the machine belongs | RFC 1036: 2.2.8 |
| Original-Encoded-Information-Types | Which body part types occur in this message | RFC 2156 |
| Original-Recipient | Original recipient information for inclusion in disposition notifications | RFC 2298 |
| Originating-Client | client software used by the originator | Nonstandard |
| Originator | used the same way asSender |
sometimes used in Usenet, nonstandard |
| Originator-Info | Information about the authentication of the originator | Internet-Draft draft-newman-msgheader-originfo-05.txt |
| Path | list of MTAs which the (Usenet) message has passed | RFC 1036: 2.1.6 |
| Phone | Phone number of originator | Nonstandard |
| PICS-Label | Ratings label to control selection (filtering) of messages according to the PICS protocol | PICS 1.1 |
| Posted-To | Newsgroup to which the message has been posted | Appears in E-mail messages |
| Precedence | Mixed usage: priority value, control of automatic replies or return-of-content faciliries, prevention of mailing list loops | Nonstandard, controversial |
| Prevent-NonDelivery-Report | Whether non-delivery report is wanted at delivery error | RFC 2156 |
| Priority | Priority for message delivery | RFC 2156 |
| Read-Receipt-To | Address to which notifications are to be sent and a request to get delivery notifications | nonstandard, discouraged |
| Received | trace of MTAs which the message has passed | RFC 822: 4.3.2; RFC 1123: 5.2.8 |
| References | In E-mail: reference to other related messages; in Usenet: reference to replied-to-articles | RFC 822: 4.6.3; RFC 1036: 2.2.5 |
| Replaces | Specifies previous message being corrected and replaced | Proposed in UseFor:draft-ietf-usefor-article-03.txt: 6.13 > |
| Reply-By | Latest time at which a reply is requested | RFC 2156 |
| Reply-To | Suggested E-mail address for replies | RFC 822: 4.4.3; RFC 1036: 2.2.1 |
| Resent-bcc | The bcc of aforwarded message |
RFC 822: 4.5.3 |
| Resent-cc | The cc of aforwarded message |
RFC 822: 4.5.2 |
| Resent-Date | The Date of aforwarded message |
RFC 822 |
| Resent-From | The From of aforwarded message |
RFC 822: 4.4.1 |
| Resent-Message-ID | The Message-ID of aforwarded message |
RFC 822: 4.6.1 |
| Resent-Reply-To | The Reply-To of aforwarded message |
RFC 822: 4.4.3 |
| Resent-Sender | The Sender of aforwarded message |
RFC 822: 4.4.2 |
| Resent-Subject | The Subject of a forwarded message |
Nonstandard |
| Resent-To | The To of aforwarded message |
RFC 822: 4.5.1 |
| Return-Path | data passed fromMAIL FROM: envelope |
RFC 821: 4.1.1; RFC 1123: 5.2.13 |
| Return-Receipt-Requested | Address to which notifications are to be sent and a request to get delivery notifications | nonstandard, discouraged |
| Return-Receipt-To | Address to which notifications are to be sent and a request to get delivery notifications | nonstandard, discouraged |
| See-Also | References to related articles (other than precursors) in Usenet | "son-of-RFC1036": 6.16 |
| Sender | The person or agent submitting the message to the network, if other than shown by theFrom header |
RFC 822: 4.4.2; RFC 1123: 5.2.15-16, 5.3.7;RFC 1036: 2.1.1 |
| Sensitivity | How sensitive it is to disclose this message to other people than the specified recipients | RFC 2156; RFC 2421 |
| Speech-Act | Speech act categorization of the message | Nonstandard |
| Status | Status of delivery for the message when stored | Non-standard, should never appear in mail in transit |
| Subject | Text that provides a summary, or indicates the nature, of the message | RFC 822: 4.7.1; RFC 1036: 2.1.4 |
| Summary | Short text describing a longer article | RFC 1036: 2.2.10 |
| Supersedes | Specifies previous message being corrected and replaced | "son-of-RFC1036": 6.14 |
| Telefax | Fax number of the originator | nonstandard |
| To | Primary recipient(s) | RFC 822: 4.5.1; RFC 1123: 5.2.15-16, 5.3.7; |
| Translated-By | Mailbox of the person who made the translation | Nonstandard |
| Translation-Of | Reference to a message which the current message is a translation of | Nonstandard |
| User-Agent | client software used by the originator | nonstandard, but often used; standardization proposed in UseFordraft draft-ietf-usefor-article-03.txt:6.16 |
| X-Abuse-Info | information for reporting abuse | nonstandard, appears in Usenet, in conjunction with X-Complaints-To orX-Report |
| X-Accept-Language | Languagepreference(s) | nonstandard, appears in Usenet and E-mail as inserted by Netscape; cf. to Accept-Languagein HTTP headers |
| X-Admin | E-mail address of news server administration | Inserted by AOLsoftware |
| X-Article-Creation-Date | Time of original creation of the article | Inserted by Deja when posting via My Deja |
| X-Attribution | The name under which the sender would like to appear in attributions when the message is quoted | Typically a nickname; see e.g. Attribution Preferences inSupercite |
| X-Authenticated-IP | Apparently the IP address of the host of the sender | Nonstandard |
| X-Authenticated-Sender | Apparently some identification of the sender | Nonstandard |
| X-Authentication-Warning | Some warning | Inserted by Pine and MHin some situations |
| X-Cache | Information about caching server software | Inserted by NNTPcache servers |
| X-Comments | Comments, usually some disclaimer | Inserted by Newsfeedssoftware, which uses X-Comments2 and X-Comments3, too, for continuation lines |
| X-Complaints-To | An E-mail address for sending complaints on the adequacy of the Usenet message | nonstandard; often appears in Usenet postings as automatically inserted by news servers |
| X-Confirm-reading-to | Address to which notifications are to be sent and a request to get delivery notifications | nonstandard, discouraged |
| X-Envelope-From | Sender, as extracted from the envelope | nonstandard; some mail servers add this field sometimes |
| X-Envelope-To | Recipient, as extracted from the envelope | nonstandard; some mail servers add this field sometimes |
| X-Face | picture of sender's face (a 48×48 bitmap) | an old invention; see e.g. About X-Face |
| X-Flags | ? | Inserted by BugTraq |
| X-Folder | Folder for saving the message | Used by Forté software |
| X-Http-Proxy | Information about using Deja for posting, including the sender's IP address | Inserted by Deja when posting via My Deja |
| X-Http-User-Agent | Web browser used for posting | Inserted by Deja when posting via My Deja |
| X-IMAP | UID as defined inIMAP | Nonstandard; only for internal mailbox format |
| X-Last-Updated | time of most recent update | Appears in FAQ postings on Usenet |
| X-List-Host | As List-Software |
Nonstandard, |
| X-Listserver | As List-Software |
Nonstandard |
| X-Loop | Used for loop detection | Nonstandard |
| X-Mailer | client software used by the originator | nonstandard |
| X-Mailer-Info | URL for info about client software used by the originator | nonstandard |
| X-Mailing-List | Information about mailing list | Nonstandard, cf. toList-something headers |
| X-MIME-Autoconverted | Information about conversion of this message on the path from sender to recipient | Nonstandard |
| X-MimeOLE | information about client software used by the originator | nonstandard, appears in Usenet articles sent by Outlook Express |
| X-MIMETrack | Info about the message passing through a router | Nonstandard |
| X-MSMail-Priority | Yet another priority indication | nonstandard, appears in Usenet articles sent by Outlook Express |
| X-MyDeja-Info | Internal user id | Inserted by Deja when posting via My Deja |
| X-Newsreader | client software used by the originator | nonstandard; often appears in Usenet messages |
| X-NNTP-Posting-Host | Posting host | Variant of NNTP-Posting-Host |
| X-No-Archive | Do not archive the message in publicly available archives | Nonstandard; seems to be honored e.g. by Deja |
| X-Notice | A comment on reporting abuse | Inserted by some news servers |
| X-Orig-Message-ID | Original Message-ID |
Appears in relayed messages |
| X-Original-Envelope-From | E-mail address of original sender | Nonstandard |
| X-Original-NNTP-Posting-Host | Name or IP address of the original posting host | Appears in Usenet postings, assumably inserted by an ISP's news server, for tracing back the computer that the customer used for posting |
| X-Original-Trace | Information (host, time, etc.) about the original posting | Appears in Usenet postings, assumably inserted by an ISP's news server, for tracing back the event of the customer's original posting; cf. to X-Trace |
| X-OriginalArrivalTime | Time when the message was delivered into the message transport system | Nonstandard |
| X-Originating-IP | Apparently the IP address of the host of the sender | Nonstandard |
| X-PMFLAGS | Internal flags indicating message status | Used by Pegasus, assumably for its internal bookkeeping only and shouldn't appear in outgoing mail |
| X-Posted-By | Attempted identification of the sender | Nonstandard |
| X-Posting-Agent | client software used by the originator | nonstandard; often appears in Usenet messages |
| X-Priority | Priority for message delivery | Eudora Pro Macintosh User Manual, Qualcomm Inc., 1988-1995 |
| X-RCPT-TO | Indication of recipient on the SMTP envelope | Nonstandard |
| X-Report | Information about reporting abuse | Inserted by Newsfeedssoftware |
| X-Report-Abuse-To | Information about reporting abuse | Yet another variant of a theme |
| X-Sender | used similarly toSender but often indicating that you may not be able to send E-mail to this address |
practice described (as non-standard) in Common Internet Message Header Fields |
| X-Server-Date | Some time denotation | Assumably indicates when the original news server received the posting |
| X-Trace | Information about posting | Nonstandard, appears in Usenet messages; usually contains posting host name and/or IP address and posting time, perhaps other tracing information too |
| X-UIDL | Unique ID for the message, local to a particular local mailbox store | Nonstandard; the POP 3specification defines the UIDL identifier but not the X-UIDL header |
| X-UML-Sequence | ? | Inserted by some mailing list programs |
| X-URI | Sometimes used with the same meaning asContent-Location, sometimes to indicate the Web home page of the sender or of his organisation |
Nonstandard |
| X-URL | Similar usage as X-URI |
Nonstandard |
| X-X-Sender | similar to X-Sender |
practice described (as non-standard) in Common Internet Message Header Fields |
| X400-Content-Return | Possible future name for Content-Return |
nonstandard |
| XPident | Appears, usually with value unknown, in Usenet postings |
|
| Xref | Identification of a message within a server | RFC 1036: 2.2.13; only for local use within a Usenet news server |
Notes on header names in general:
- By RFC 822 clause 3.4.7, header names are case-insensitive. The spellings above try to correspond to those used in the specifications. For example, RFC 822 writes
cc, though in practiceCcorCChas become more common; they are all equivalent of course. - In RFC 822 clause 4.7.4 says: "A limited number of common fields have been defined in this document. As network mail requirements dictate, additional fields may be standardized. To provide user-defined fields with a measure of safety, in name selection, such extension-fields will never have names that begin with the string
X-." It also specifies a registration authority for extension fields, assumably meaning that all header field names not beginning withX-should be registered. In practice, there doesn't seem to have been any central registry; and headers for private, experimental, or even public use have been named using or not usingX-prefix in a rather random fashion. See the proposal Mail and Netnews Header field Registration Procedure(expired Internet-Draft) by Jacob Palme for an explanation of what problems have been caused by this and how they might be solved.
There is surely a much larger set of X- headers used somewhere than the list above tells. It could be some sort of sports to add headers just for fun, on user agents that allow arbitrary headers to be inserted. Examples:X-Anagram: look vanilla, aim elite
X-Eric-Conspiracy: there is no conspiracy
Explanations of abbreviations:
- MIME
- Multipurpose Internet Mail Extensions, a set of specifications for extending the format of Internet E-mail to allow non-US-ASCII textual messages, non-textual messages, multipart message bodies, and non-US-ASCII information in message headers; used outside E-mail too
- MTA
- Message Transfer Agent, generically a program responsible for delivering E-mail messages
- PICS
- Platform for Internet Content Selection, a method for associating metadata (PICS labels) to be associated with Internet content, so that users can filter content; originally designed to help parents and teachers control what children access on the Internet.
This document basically tries to combine some content from July 2000 version of the Internet-draft Common Internet Message Header Fields, (a planned revision of RFC 2076; there's now a newer version of the draft available) with observations from headers actually used in different contexts. Information about the following headers has been taken from other sources: Abuse-Reports-To, Cache-Post-Path, Envelope-ID, Injector-Info, Mail-Copies-To, NNTP-Posting-Date, NNTP-Posting-Host, NNTP-Posting-Time, NNTP-Proxy-Relay, Old-Date,Old-X-Envelope-From, Old-X-Envelope-To, Posted-To, User-Agent, X-Abuse-Info, X-Accept-Language, X-Admin, X-Article-Creation-Date, X-Attribution, X-Authenticated-ID, X-Authenticated-Sender, X-Authenticated-User, X-Authentication-Warning, X-Cache, X-CommentsX-Complaints-To, X-Face, X-Flags, X-Folder, X-Http-Proxy, X-Http-User-Agent, X-Mailing-List, X-MSMail-Priority, X-MyDeja-Info, X-NNTP-Posting-Host, X-Notice, X-Orig-Message-ID,X-Original-Envelope-From, X-Original-NNTP-Posting-Host, X-Original-Trace, X-Originating-IP,X-PMFLAGS, X-Posted-By, X-Posting-Agent, X-Report, X-Report-Abuse-To, X-Server-Date, X-Trace, X-UML-Sequence, XPident.
Quick reference to HTTP headers
This document lists all the message headers defined in the HTTP/1.1 protocol, with short descriptions. In the list, the name of the header is a link to its definition in the protocol itself. Note that some of the headers are also used in Internet E-mail and in Usenet; see Quick reference to Internet message headers.
The kind of the header is indicated as follows:
| [Entity] | Metainformation about an entity body or resource. |
| [General] | Applicable for use both in request and in response messages. |
| [Request] | Sent by a browser or other client to a server |
| [Response] | Sent by a server in a response to a request |
Accept[Request]- Specifies which Internet media types are acceptable for the response and to assign preferences to them.
Accept-Charset[Request]- Specifies which character encodings (confusingly called "charsets") are acceptable for the response and to assign preferences to them.
Accept-Encoding[Request]- Specifies which data format tranformations, confusingly called content (en)codings, such as compression mechanisms, are acceptable for the response and to assign preferences to them.
Accept-Language[Request]- Specifies which natural languages are acceptable for the response and to assign preferences to them. Useful for language negotation.
Accept-Ranges[Response]- Indicates the server's acceptance of range requests for a resource.
Age[Response]- Gives the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server.
Allow[Entity]- Lists the set of methods supported by the resource identified by the Request-URI. The purpose is to inform the recipient of valid methods associated with the resource.
Authorization[Request]- Consists of credentials containing the authentication information of the client for the realm of the resource being requested
Cache-Control[General]- Specifies directives that must be obeyed by all caching mechanisms along the request/response chain.
Connection[General]- Specifies options that are desired for the particular connection and must not be communicated by proxies over further connections.
Content-Encoding[Entity]- Used as a modifier to the media-type, to indicate what additional data format transformations such as compression have been applied to the entity-body.
Content-Language[Entity]- Specifies the natural language(s) of the intended audience for the enclosed entity. But according to RFC 3282, specifies the language(s) of the entity.
Content-Length[Entity]- Indicates the size (in octets) of the entity-body that is sent or that would have been sent if it has reen requested.
Content-Location[Entity]- Supplies the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI.
Content-MD5[Entity]- An MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.
Content-Range[Entity]- Sent with a partial entity-body to specify where in the full entity-body the partial body should be applied.
Content-Type[Entity]- Specifies the Internet media type of the entity-body that is sent or would have been sent if requested. Often includes a
charsetparameter specifying the character encoding. Date[General]- Date and time at which the message was originated.
ETag[Response]- Provides the current value of the entity tag for the requested variant, forcaching purposes.
Expect[Request]- Indicates that particular server behaviors are required by the client.
Expires[Entity]- Gives the date/time after which the response is considered stale, forcaching purposes.
From[Request]- The Internet e-mail address for the human user who controls the requesting browser or other client.
Host[Request]- Specifies the Internet host and port number of the resource being requested. Obligatory in all HTTP/1.1 requests.
If-Match[Request]- Used with a method to make it conditional: a client that has previously obtained entities can verify that one of those entities is current by including a list of their associated entity tags in the
If-Matchheader field. If-Modified-Since[Request]- Used with a method to make it conditional: if the requested variant has not been modified since the time specified in this field, the server will not return the entity but information about this fact.
If-None-Match[Request]- Used with a method to make it conditional: a client that has previously obtained entities can verify that none of those entities is current by including a list of their associated entity tags in the
If-None-Matchheader field. If-Range[Request]- Used together with
Rangeto say: "if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity". If-Unmodified-Since[Request]- Used with a method to make it conditional: if the requested variant has been modified since the time specified in this field, the server will not perform the requested operation but information about this fact.
Last-Modified[Entity]- Indicates the date and time at which the origin server believes the variant was last modified.
Location[Response]- Redirects the recipient to a location other than the Request-URI for completion of the request or identification of a new resource.
Max-Forwards[Request]- Provides a mechanism with the
TRACEandOPTIONSmethods to limit the number of proxies or gateways that can forward the request to the next inbound server. Pragma[General]- Used to include implementation-specific directives that might (optionally) apply to any recipient along the request/response chain.
Proxy-Authenticate[Response]- Included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.
Proxy-Authorization[Request]- Used by a client to identify itself (or its user) to a proxy which requires authentication.
Range[Request]- Restricts the request to some part(s), specified as range(s) of octets, in the resource.
Referer[Request]- Used by a client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained.
Retry-After[Response]- Indicates how long the service is expected to be unavailable to the requesting client.
Server[Response]- Contains information about the software used by the origin server to handle the request.
TE[Request]- Indicates what extension transfer-codings the client is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding.
Trailer[General]- Indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding.
Transfer-Encoding[General]- Indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the
Content-Encodingin that the transfer-coding is a property of the message, not of the entity. Upgrade[General]- Used by a client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The server uses the
Upgradeheader to indicate which protocol(s) are being switched. User-Agent[Request]- Contains information about the user agent (client) originating the request
Vary[Response]- Indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation.
Via[General]- Used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses.
Warning[General]- Carries additional information about the status or transformation of a message which might not be reflected in the message.
WWW-Authenticate[Response]- Used in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
There might be other headers in use as well, but with no authoritative definition.
You could use e.g. Tipjar's tester to see what headers your browser actually sends. It displays a collection of "environment variables", and those beginning with HTTP_ derive from HTTP headers, as per CGI rules; e.g., HTTP_ACCEPTcorresponds to the Accept header. And you could use e.g. Delorie's HTTP Viewerto see what headers a Web server actually sends, in response to a simple request.
浙公网安备 33010602011771号