Changeset 965


Ignore:
Timestamp:
Jul 29, 2010, 11:11:34 PM (9 years ago)
Author:
fielding@…
Message:

Addresses #109: Clarify entity / representation / variant terminology

Removed entity-header adjective and ABNF and clarified distinction
between payload and representation.

Uncapitalize the phrase effective request URI so that it doesn't
dominate the prose, and define the term "target resource" to be
used instead of the "resource identified by the effective request URI".

Location:
draft-ietf-httpbis/latest
Files:
7 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r963 r965  
    2424  <!ENTITY diff-mime              "<xref target='Part3' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2525  <!ENTITY representation         "<xref target='Part3' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    26   <!ENTITY entity-header-fields   "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2726  <!ENTITY header-cache-control   "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2827  <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    521520  <x:anchor-alias value="request-header"/>
    522521  <x:anchor-alias value="response-header"/>
    523   <x:anchor-alias value="entity-header"/>
    524522  <x:anchor-alias value="Cache-Control"/>
    525523  <x:anchor-alias value="Pragma"/>
     
    534532</artwork></figure>
    535533<figure><!-- Part3--><artwork type="abnf2616">
    536   <x:ref>entity-header</x:ref>   = &lt;entity-header, defined in &entity-header-fields;&gt;
    537534  <x:ref>MIME-Version</x:ref>    = &lt;MIME-Version, defined in &header-mime-version;&gt;
    538535</artwork></figure>
     
    556553
    557554<section title="Client/Server Messaging" anchor="operation">
    558 <iref item="client"/>
    559 <iref item="server"/>
    560 <iref item="connection"/>
     555<iref primary="true" item="client"/>
     556<iref primary="true" item="server"/>
     557<iref primary="true" item="connection"/>
    561558<t>
    562559   HTTP is a stateless request/response protocol that operates by exchanging
     
    567564   sending HTTP responses.
    568565</t>
    569 <iref item="user agent"/>
    570 <iref item="origin server"/>
     566<iref primary="true" item="user agent"/>
     567<iref primary="true" item="origin server"/>
     568<iref primary="true" item="browser"/>
     569<iref primary="true" item="spider"/>
    571570<t>
    572571   Note that the terms client and server refer only to the roles that
     
    576575   such as a WWW browser, editor, or spider (web-traversing robot), and
    577576   the term "origin server" to refer to the program that can originate
    578    authoritative responses to a request.
     577   authoritative responses to a request.  For general requirements, we use
     578   the term "sender" to refer to whichever component sent a given message
     579   and the term "recipient" to refer to any component that receives the
     580   message.
    579581</t>
    580582<t>
     
    589591                                &lt;   response
    590592</artwork></figure>
    591 <iref item="message"/>
    592 <iref item="request"/>
    593 <iref item="response"/>
     593<iref primary="true" item="message"/>
     594<iref primary="true" item="request"/>
     595<iref primary="true" item="response"/>
    594596<t>
    595597   A client sends an HTTP request to the server in the form of a request
     
    639641
    640642<section title="Intermediaries" anchor="intermediaries">
     643<iref primary="true" item="intermediary"/>
    641644<t>
    642645   A more complicated situation occurs when one or more intermediaries
     
    665668</t>
    666669<t>
    667 <iref item="upstream"/><iref item="downstream"/>
    668 <iref item="inbound"/><iref item="outbound"/>
     670<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
     671<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
    669672   We use the terms "upstream" and "downstream" to describe various
    670673   requirements in relation to the directional flow of a message:
     
    674677   the origin server and "outbound" means toward the user agent.
    675678</t>
    676 <t><iref item="proxy"/>
     679<t><iref primary="true" item="proxy"/>
    677680   A "proxy" is a message forwarding agent that is selected by the
    678681   client, usually via local configuration rules, to receive requests
     
    685688   sake of security, annotation services, or shared caching.
    686689</t>
    687 <t><iref item="gateway"/><iref item="reverse proxy"/>
     690<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
    688691   A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
    689692   as a layer above some other server(s) and translates the received
     
    692695   multiple machines.
    693696   Unlike a proxy, a gateway receives requests as if it were the
    694    origin server for the requested resource; the requesting client
     697   origin server for the target resource; the requesting client
    695698   will not be aware that it is communicating with a gateway.
    696699   A gateway communicates with the client as if the gateway is the
     
    701704   specification.
    702705</t>
    703 <t><iref item="tunnel"/>
     706<t><iref primary="true" item="tunnel"/>
    704707   A "tunnel" acts as a blind relay between two connections
    705708   without changing the messages. Once active, a tunnel is not
     
    714717
    715718<section title="Caches" anchor="caches">
    716 <iref item="cache"/>
     719<iref primary="true" item="cache"/>
    717720<t>
    718721   A "cache" is a local store of previous response messages and the
     
    735738                  &lt;             &lt;
    736739</artwork></figure>
    737 <t><iref item="cacheable"/>
     740<t><iref primary="true" item="cacheable"/>
    738741   A response is "cacheable" if a cache is allowed to store a copy of
    739742   the response message for use in answering subsequent requests.
     
    11281131   like UTF-16 might introduce security flaws due to the differing ways
    11291132   that such parsers interpret invalid characters.
     1133</t>
     1134<t>
     1135   HTTP allows the set of defined header fields to be extended without
     1136   changing the protocol version (see <xref target="header.field.registration"/>).
     1137   However, such fields might not be recognized by a downstream recipient
     1138   and might be stripped by non-transparent intermediaries.
     1139   Unrecognized header fields &MUST; be forwarded by transparent proxies
     1140   and &SHOULD; be ignored by a recipient.
    11301141</t>
    11311142</section>
     
    14441455   experimental header fields might be given the semantics of general
    14451456   header fields if all parties in the communication recognize them to
    1446    be general-header fields. Unrecognized header fields are treated as
    1447    entity-header fields.
     1457   be general-header fields.
    14481458</t>
    14491459</section>
     
    14601470<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/>
    14611471  <x:ref>Request</x:ref>       = <x:ref>Request-Line</x:ref>              ; <xref target="request-line"/>
    1462                   *(( <x:ref>general-header</x:ref>        ; <xref target="general.header.fields"/>
    1463                    / <x:ref>request-header</x:ref>         ; &request-header-fields;
    1464                    / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields;
     1472                  *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )    ; <xref target="header.fields"/>
    14651473                  <x:ref>CRLF</x:ref>
    14661474                  [ <x:ref>message-body</x:ref> ]          ; <xref target="message.body"/>
     
    16581666
    16591667<section title="Effective Request URI" anchor="effective.request.uri">
    1660   <iref primary="true" item="Effective Request URI"/>
     1668  <iref primary="true" item="effective request URI"/>
     1669  <iref primary="true" item="target resource"/>
    16611670<t>
    16621671   HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
    1663    for the resource they are intended for; instead, the value needs to be inferred from the
    1664    request-target, Host header and other context. The result of this process is
    1665    the "Effective Request URI".
    1666 </t>
    1667 <t>
    1668    If the request-target is an absolute-URI, then the Effective Request URI is
     1672   for the target resource; instead, the URI needs to be inferred from the
     1673   request-target, Host header field, and connection context. The result of
     1674   this process is called the "effective request URI".  The "target resource"
     1675   is the resource identified by the effective request URI.
     1676</t>
     1677<t>
     1678   If the request-target is an absolute-URI, then the effective request URI is
    16691679   the request-target.
    16701680</t>
    16711681<t>
    16721682   If the request-target uses the path-absolute (plus optional query) syntax
    1673    or if it is just the asterisk "*", then the Effective Request URI is
     1683   or if it is just the asterisk "*", then the effective request URI is
    16741684   constructed by concatenating
    16751685</t>
     
    17041714<figure>
    17051715<preamble>
    1706    Example 1: the Effective Request URI for the message
     1716   Example 1: the effective request URI for the message
    17071717</preamble>
    17081718<artwork type="example" x:indent-with="  ">
     
    17191729<figure>
    17201730<preamble>
    1721    Example 2: the Effective Request URI for the message
     1731   Example 2: the effective request URI for the message
    17221732</preamble>
    17231733<artwork type="example" x:indent-with="  ">
     
    17311741</figure>
    17321742<t>
    1733    Effective Request URIs are compared using the rules described in
     1743   Effective request URIs are compared using the rules described in
    17341744   <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
    17351745   be treated as equivalent to an absolute path of "/".
     
    17481758<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Response"/>
    17491759  <x:ref>Response</x:ref>      = <x:ref>Status-Line</x:ref>               ; <xref target="status-line"/>
    1750                   *(( <x:ref>general-header</x:ref>        ; <xref target="general.header.fields"/>
    1751                    / <x:ref>response-header</x:ref>        ; &response-header-fields;
    1752                    / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields;
     1760                  *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )    ; <xref target="header.fields"/>
    17531761                  <x:ref>CRLF</x:ref>
    17541762                  [ <x:ref>message-body</x:ref> ]          ; <xref target="message.body"/>
     
    20312039   The chunked encoding modifies the body of a message in order to
    20322040   transfer it as a series of chunks, each with its own size indicator,
    2033    followed by an &OPTIONAL; trailer containing entity-header fields. This
     2041   followed by an &OPTIONAL; trailer containing header fields. This
    20342042   allows dynamically produced content to be transferred along with the
    20352043   information necessary for the recipient to verify that it has
     
    20522060  <x:ref>chunk-ext-val</x:ref>  = <x:ref>token</x:ref> / <x:ref>quoted-str-nf</x:ref>
    20532061  <x:ref>chunk-data</x:ref>     = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets
    2054   <x:ref>trailer-part</x:ref>   = *( <x:ref>entity-header</x:ref> <x:ref>CRLF</x:ref> )
     2062  <x:ref>trailer-part</x:ref>   = *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
    20552063 
    20562064  <x:ref>quoted-str-nf</x:ref>  = <x:ref>DQUOTE</x:ref> *( <x:ref>qdtext-nf</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref>
     
    28432851   related to message framing and transport protocols.
    28442852</t>
    2845 <t>
    2846    For entity-header fields, both sender and recipient refer to either the
    2847    client or the server, depending on who sends and who receives the message.
    2848 </t>
    28492853
    28502854<section title="Connection" anchor="header.connection">
     
    32313235   &MUST; be listed in the order in which they were applied.
    32323236   Additional information about the encoding parameters &MAY; be provided
    3233    by other entity-header fields not defined by this specification.
     3237   by other header fields not defined by this specification.
    32343238</t>
    32353239<t>
     
    49364940<x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP )
    49374941<x:ref>Reason-Phrase</x:ref> = *( WSP / VCHAR / obs-text )
    4938 <x:ref>Request</x:ref> = Request-Line *( ( general-header / request-header /
    4939  entity-header ) CRLF ) CRLF [ message-body ]
     4942<x:ref>Request</x:ref> = Request-Line *( header-field CRLF ) CRLF [ message-body ]
    49404943<x:ref>Request-Line</x:ref> = Method SP request-target SP HTTP-Version CRLF
    4941 <x:ref>Response</x:ref> = Status-Line *( ( general-header / response-header /
    4942  entity-header ) CRLF ) CRLF [ message-body ]
     4944<x:ref>Response</x:ref> = Status-Line *( header-field CRLF ) CRLF [ message-body ]
    49434945
    49444946<x:ref>Status-Code</x:ref> = 3DIGIT
     
    50015003 / %x53.75.6E.64.61.79 ; Sunday
    50025004
    5003 <x:ref>entity-header</x:ref> = &lt;entity-header, defined in [Part3], Section 3.1&gt;
    5004 
    50055005<x:ref>field-content</x:ref> = *( WSP / VCHAR / obs-text )
    50065006<x:ref>field-name</x:ref> = token
     
    50815081<x:ref>time-of-day</x:ref> = hour ":" minute ":" second
    50825082<x:ref>token</x:ref> = 1*tchar
    5083 <x:ref>trailer-part</x:ref> = *( entity-header CRLF )
     5083<x:ref>trailer-part</x:ref> = *( header-field CRLF )
    50845084<x:ref>transfer-coding</x:ref> = "chunked" / "compress" / "deflate" / "gzip" /
    50855085 transfer-extension
     
    56385638    </t>
    56395639    <t>
     5640      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
     5641      "Clarify entity / representation / variant terminology"
     5642    </t>
     5643    <t>
    56405644      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
    56415645      "consider removing the 'changes from 2068' sections"
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r954 r965  
    277277   agreed upon semantics of the HTTP uniform interface, the intentions defined
    278278   by each request method, and the various response messages that might be
    279    expected as a result of applying that method for the requested resource.
     279   expected as a result of applying that method to the target resource.
    280280</t>
    281281<t>
     
    434434<t>
    435435   The Method token indicates the method to be performed on the resource
    436    identified by the Effective Request URI (&effective-request-uri;). The
     436   identified by the effective request URI (&effective-request-uri;). The
    437437   method is case-sensitive.
    438438</t>
     
    451451<t>
    452452   The list of methods allowed by a resource can be specified in an
    453    Allow header field (<xref target="header.allow"/>). The return code of the response
     453   Allow header field (<xref target="header.allow"/>). The status code of the response
    454454   always notifies the client whether a method is currently allowed on a
    455455   resource, since the set of allowed methods can change dynamically. An
    456    origin server &SHOULD; return the status code 405 (Method Not Allowed)
     456   origin server &SHOULD; respond with the status code 405 (Method Not Allowed)
    457457   if the method is known by the origin server but not allowed for the
    458    requested resource, and 501 (Not Implemented) if the method is
     458   resource, and 501 (Not Implemented) if the method is
    459459   unrecognized or not implemented by the origin server. The methods GET
    460460   and HEAD &MUST; be supported by all general-purpose servers. All other
     
    522522   experimental header fields &MAY; be given the semantics of request-header
    523523   fields if all parties in the communication recognize them to
    524    be request-header fields. Unrecognized header fields are treated as
    525    entity-header fields.
     524   be request-header fields.
    526525</t>
    527526</section>
     
    635634   information about the response which cannot be placed in the Status-Line.
    636635   These header fields give information about the server and about
    637    further access to the resource identified by the Effective Request URI
     636   further access to the resource identified by the effective request URI
    638637   (&effective-request-uri;).
    639638</t>
     
    655654   experimental header fields &MAY; be given the semantics of response-header
    656655   fields if all parties in the communication recognize them to
    657    be response-header fields. Unrecognized header fields are treated as
    658    entity-header fields.
     656   be response-header fields.
    659657</t>
    660658</section>
     
    678676<section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
    679677<t>
    680    It is sometimes necessary to determine the identity of the resource
     678   It is sometimes necessary to determine an identifier for the resource
    681679   associated with a representation.
    682680</t>
     
    687685<t>
    688686   In the common case, an HTTP response is a representation of the resource
    689    located at the Effective Request URI (see &effective-request-uri;). However,
     687   located at the effective request URI (see &effective-request-uri;). However,
    690688   this is not always the case. To determine the URI of the resource a
    691689   response is associated with, the following rules are used (with the first
     
    694692<t><list style="numbers">
    695693   <t>If the response status code is 200 or 203 and the request method was GET,
    696    the response is a representation of the resource at the Effective Request URI.</t>
     694   the response payload is a representation of the resource identified by the effective request URI.</t>
    697695   <t>If the response status code is 204, 206, or 304 and the request method was GET
    698    or HEAD, the response is a partial representation of the resource at the
    699    Effective Request URI (see &caching-combining-headers;).</t>
     696   or HEAD, the response payload is a partial representation of the resource identified
     697   by the effective request URI (see &caching-combining-headers;).</t>
    700698   <t>If the response has a Content-Location header, and that URI is the same
    701    as the Effective Request URI, the response is a representation of the
    702    resource at the Effective Request URI.</t>
     699   as the effective request URI, the response payload is a representation of the
     700   resource identified by the effective request URI.</t>
    703701   <t>If the response has a Content-Location header, and that URI is not the
    704    same as the Effective Request URI, the response asserts that it is a
    705    representation of the resource at the Content-Location URI (but it might not
    706    be).</t>
     702   same as the effective request URI, then the response asserts that its
     703   payload is a representation of the resource identified by the
     704   Content-Location URI. However, such an assertion cannot be trusted unless
     705   it can be verified by other means (not defined by HTTP).</t>
    707706   <t>Otherwise, the response is a representation of an anonymous (i.e.,
    708707   unidentified) resource.</t>
     
    776775   The OPTIONS method represents a request for information about the
    777776   communication options available on the request/response chain
    778    identified by the Effective Request URI. This method allows the client to
     777   identified by the effective request URI. This method allows the client to
    779778   determine the options and/or requirements associated with a resource,
    780779   or the capabilities of a server, without implying a resource action
     
    835834   The GET method means retrieve whatever information (in the form of a
    836835   representation) currently corresponds to the resource identified by the
    837    Effective Request URI.
     836   effective request URI.
    838837</t>
    839838<t>   
    840    If the Effective Request URI identifies a data-producing process, it is the
     839   If the effective request URI identifies a data-producing process, it is the
    841840   produced data which shall be returned as the representation in the response and not
    842841   the source text of the process, unless that text happens to be the output of
     
    903902   The POST method is used to request that the origin server accept the
    904903   representation enclosed in the request as data to be processed by the resource
    905    identified by the Effective Request URI. POST is designed
     904   identified by the effective request URI. POST is designed
    906905   to allow a uniform method to cover the following functions:
    907906  <list style="symbols">
     
    924923<t>
    925924   The actual function performed by the POST method is determined by the
    926    server and is usually dependent on the Effective Request URI.
     925   server and is usually dependent on the effective request URI.
    927926</t>
    928927<t>
     
    958957<t>
    959958   The PUT method requests that the enclosed representation be stored at the
    960    Effective Request URI. If the Effective Request URI refers to an already
     959   effective request URI. If the effective request URI refers to an already
    961960   existing resource, the enclosed representation &SHOULD; be considered a
    962961   modified version of the one residing on the origin server. Otherwise, if the
    963    Effective Request URI does not point to an existing resource, and that URI is
     962   effective request URI does not point to an existing resource, and that URI is
    964963   capable of being defined as a new resource by the requesting user
    965964   agent, the origin server can create the resource with that URI.
    966965</t>
    967966<t>   
    968    If a new resource is created at the Effective Request URI, the origin
     967   If a new resource is created at the effective request URI, the origin
    969968   server &MUST; inform the user agent
    970969   via the 201 (Created) response. If an existing resource is modified,
     
    973972</t>
    974973<t>   
    975    If the resource identified by the Effective Request URI could not be
     974   If the resource identified by the effective request URI could not be
    976975   created or modified, an appropriate error response &SHOULD; be given
    977976   that reflects the nature of the problem.
     
    983982<t>
    984983   If the request passes through a cache that has one or more stored
    985    responses for the Effective Request URI, those stored responses
     984   responses for the effective request URI, those stored responses
    986985   &SHOULD; be marked as stale if the response to the PUT request
    987986   has a success status code. Responses to the PUT method are
     
    990989<t>
    991990   The fundamental difference between the POST and PUT requests is
    992    reflected in the different meaning of the Effective Request URI. The URI in a
     991   reflected in the different meaning of the effective request URI. The URI in a
    993992   POST request identifies the resource that will handle the enclosed
    994993   representation. That resource might be a data-accepting process, a gateway to
     
    10151014</t>
    10161015<t>
    1017    Unless otherwise specified for a particular entity-header, the
    1018    entity-headers in the PUT request &SHOULD; be applied to the resource
    1019    created or modified by the PUT.
     1016   Header fields in a PUT request that are recognized as representation
     1017   metadata &SHOULD; be applied to the resource created or modified by
     1018   the PUT.  Unrecognized header fields &SHOULD; be ignored.
    10201019</t>
    10211020</section>
     
    10261025<t>
    10271026   The DELETE method requests that the origin server delete the resource
    1028    identified by the Effective Request URI. This method &MAY; be overridden by
     1027   identified by the effective request URI. This method &MAY; be overridden by
    10291028   human intervention (or other means) on the origin server. The client cannot
    10301029   be guaranteed that the operation has been carried out, even if the
     
    10421041</t>
    10431042<t>
    1044    If the request passes through a cache and the Effective Request URI
     1043   If the request passes through a cache and the effective request URI
    10451044   identifies one or more currently cached representations, those entries &SHOULD; be
    10461045   treated as stale. Responses to the DELETE method are not cacheable.
     
    11681167  <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/>
    11691168<t>
    1170    The request has succeeded. The information returned with the response
     1169   The request has succeeded. The payload returned with the response
    11711170   is dependent on the method used in the request, for example:
    11721171  <list style="hanging">
    11731172    <t hangText="GET">
    1174           a representation corresponding to the requested resource is sent in
    1175           the response;
     1173          a representation of the resource corresponding to the effective
     1174          request URI is sent in the response;
    11761175    </t>
    11771176    <t hangText="HEAD">
    1178           the entity-header fields corresponding to the requested
    1179           resource are sent in the response without any message-body;
     1177          the same representation as GET, except without the message-body;
    11801178    </t>
    11811179    <t hangText="POST">
     
    12431241  <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/>
    12441242<t>
    1245    The returned metadata in the entity-header is not the
     1243   The returned metadata in the header fields is not the
    12461244   definitive set as available from the origin server, but is gathered
    12471245   from a local or a third-party copy. The set presented &MAY; be a subset
     
    12661264   additional content to return in the response payload body.  The
    12671265   resource metadata and representation metadata in the response message's
    1268    header fields refer to the requested resource and its current
    1269    representation, respectively, after the requested action.
     1266   header fields refer to the target resource
     1267   and its current representation, respectively, after the requested action.
    12701268   For example, if a 204 status code is received in response to a PUT
    12711269   and the response contains an ETag header field, then the value of
    12721270   that field is the current entity-tag for the representation that
    1273    was successfully PUT to the requested resource.
     1271   was successfully PUT.
    12741272</t>
    12751273<t>
     
    13401338  <iref primary="true" item="Status Codes" subitem="300 Multiple Choices" x:for-anchor=""/>
    13411339<t>
    1342    The requested resource corresponds to any one of a set of
    1343    representations, each with its own specific location, and agent-driven
     1340   The target resource more than one
     1341   representation, each with its own specific location, and agent-driven
    13441342   negotiation information (&content-negotiation;) is being provided so that
    1345    the user (or user agent) can select a preferred representation and
    1346    redirect its request to that location.
     1343   the user (or user agent) can select a preferred representation by
     1344   redirecting its request to that location.
    13471345</t>
    13481346<t>
    13491347   Unless it was a HEAD request, the response &SHOULD; include a representation
    1350    containing a list of resource characteristics and location(s) from
     1348   containing a list of representation metadata and location(s) from
    13511349   which the user or user agent can choose the one most appropriate. The
    13521350   data format is specified by the media type given in the Content-Type
     
    13731371  <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/>
    13741372<t>
    1375    The requested resource has been assigned a new permanent URI and any
     1373   The target resource has been assigned a new permanent URI and any
    13761374   future references to this resource &SHOULD; use one of the returned
    13771375   URIs.  Clients with link editing capabilities ought to automatically
    1378    re-link references to the Effective Request URI to one or more of the new
     1376   re-link references to the effective request URI to one or more of the new
    13791377   references returned by the server, where possible.
    13801378</t>
     
    14101408  <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/>
    14111409<t>
    1412    The requested resource resides temporarily under a different URI.
     1410   The target resource resides temporarily under a different URI.
    14131411   Since the redirection might be altered on occasion, the client &SHOULD;
    1414    continue to use the Effective Request URI for future requests.
     1412   continue to use the effective request URI for future requests.
    14151413</t>
    14161414<t>
     
    14571455   representation corresponding to the response, be redirected again,
    14581456   or end with an error status.  The Location URI is not a substitute
    1459    reference for the originally requested resource.
     1457   reference for the effective request URI.
    14601458</t>
    14611459<t>
     
    14711469   resource does not have a representation of its own that can be
    14721470   transferred by the server over HTTP.  The Location URI indicates a
    1473    resource that is descriptive of the requested resource such that
    1474    the follow-on representation might be useful without implying that
    1475    it adequately represents the previously requested resource.
     1471   resource that is descriptive of the target resource, such that the
     1472   follow-on representation might be useful to recipients without
     1473   implying that it adequately represents the target resource.
    14761474   Note that answers to the questions of what can be represented, what
    14771475   representations are adequate, and what might be a useful description
     
    15201518  <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/>
    15211519<t>
    1522    The requested resource resides temporarily under a different URI.
     1520   The target resource resides temporarily under a different URI.
    15231521   Since the redirection can change over time, the client &SHOULD;
    1524    continue to use the Effective Request URI for future requests.
     1522   continue to use the effective request URI for future requests.
    15251523</t>
    15261524<t>
     
    16101608  <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/>
    16111609<t>
    1612    The server has not found anything matching the Effective Request URI. No
     1610   The server has not found anything matching the effective request URI. No
    16131611   indication is given of whether the condition is temporary or
    16141612   permanent. The 410 (Gone) status code &SHOULD; be used if the server
     
    16251623  <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/>
    16261624<t>
    1627    The method specified in the Request-Line is not allowed for the
    1628    resource identified by the Effective Request URI. The response &MUST; include an
     1625   The method specified in the Request-Line is not allowed for the target
     1626   resource. The response &MUST; include an
    16291627   Allow header containing a list of valid methods for the requested
    16301628   resource.
     
    17141712  <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/>
    17151713<t>
    1716    The requested resource is no longer available at the server and no
     1714   The target resource is no longer available at the server and no
    17171715   forwarding address is known. This condition is expected to be
    17181716   considered permanent. Clients with link editing capabilities &SHOULD;
    1719    delete references to the Effective Request URI after user approval. If the
     1717   delete references to the effective request URI after user approval. If the
    17201718   server does not know, or has no facility to determine, whether or not
    17211719   the condition is permanent, the status code 404 (Not Found) &SHOULD; be
     
    17841782  <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/>
    17851783<t>
    1786    The server is refusing to service the request because the Effective Request URI
     1784   The server is refusing to service the request because the effective request URI
    17871785   is longer than the server is willing to interpret. This rare
    17881786   condition is only likely to occur when a client has improperly
     
    17921790   itself), or when the server is under attack by a client attempting to
    17931791   exploit security holes present in some servers using fixed-length
    1794    buffers for reading or manipulating the Effective Request URI.
     1792   buffers for reading or manipulating the effective request URI.
    17951793</t>
    17961794</section>
     
    18011799<t>
    18021800   The server is refusing to service the request because the representation of
    1803    the request is in a format not supported by the requested resource
     1801   the request is in a format not supported by the target resource
    18041802   for the requested method.
    18051803</t>
     
    19321930   related to request and response semantics.
    19331931</t>
    1934 <t>
    1935    For entity-header fields, both sender and recipient refer to either the
    1936    client or the server, depending on who sends and who receives the message.
    1937 </t>
    19381932
    19391933<section title="Allow" anchor="header.allow">
     
    19441938<t>
    19451939   The "Allow" response-header field lists the set of methods advertised as
    1946    supported by the resource identified by the Effective Request URI. The purpose of
     1940   supported by the target resource. The purpose of
    19471941   this field is strictly to inform the recipient of valid methods
    19481942   associated with the resource.
     
    21772171<t>
    21782172   The "Referer" [sic] request-header field allows the client to specify the
    2179    URI of the resource from which the Effective Request URI was obtained (the
     2173   URI of the resource from which the effective request URI was obtained (the
    21802174   "referrer", although the header field is misspelled.).
    21812175</t>
     
    21892183</t>
    21902184<t>
    2191    If the Effective Request URI was obtained from a source that does not have its own
     2185   If the effective request URI was obtained from a source that does not have its own
    21922186   URI (e.g., input from the user keyboard), the Referer field &MUST; either be
    21932187   sent with the value "about:blank", or not be sent at all. Note that this
     
    22062200<t>
    22072201   If the field value is a relative URI, it &SHOULD; be interpreted
    2208    relative to the Effective Request URI. The URI &MUST-NOT; include a fragment. See
     2202   relative to the effective request URI. The URI &MUST-NOT; include a fragment. See
    22092203   <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
    22102204</t>
     
    32903284<t>
    32913285  Deprecate 305 Use Proxy status code, because user agents did not implement it.
    3292   It used to indicate that the requested resource must be accessed through the
     3286  It used to indicate that the target resource must be accessed through the
    32933287  proxy given by the Location field. The Location field gave the URI of the
    32943288  proxy. The recipient was expected to repeat this single request via the proxy.
  • draft-ietf-httpbis/latest/p3-payload.xml

    r942 r965  
    260260  </list>
    261261</t>
    262 <t>
    263   <iref item="payload"/>
    264   <x:dfn>payload</x:dfn>
    265   <list>
    266     <t>
    267       The information transferred within a given message is called the
    268       payload, consisting  of optional payload metadata and an optional
    269       payload body.  The payload in HTTP is always a partial or complete
    270       representation of some resource, though which resource is represented
    271       is dependent on the type of message (request or response), the
    272       request method, and the response status code.
    273     </t>
    274   </list>
    275 </t>
    276 <t>
    277   <iref item="representation"/>
    278   <x:dfn>representation</x:dfn>
    279   <list>
    280     <t>
    281       A representation is information in a format that can be readily
    282       communicated from one party to another.  For our purposes, a
    283       representation is binary data and its associated metadata.
    284       A representation of a resource is information that reflects the
    285       state of that resource, as observed at some point in the past
    286       or to be desired at some point in the future.
    287     </t>
    288   </list>
    289 </t>
    290262</section>
    291263
     
    705677</section>
    706678
    707 <section title="Representation" anchor="representation">
    708 <t>
    709    Request and Response messages &MAY; transfer a representation if not otherwise
    710    restricted by the request method or response status code. A representation
    711    consists of entity-header fields and a representation body, although some
    712    responses will only include the entity-headers.
    713 </t>
    714 <t>
    715    In this section, both sender and recipient refer to either the client
    716    or the server, depending on who sends and who receives the message.
    717 </t>
    718 
    719 <section title="Entity Header Fields" anchor="entity.header.fields">
    720   <x:anchor-alias value="entity-header"/>
    721   <x:anchor-alias value="extension-header"/>
    722 <t>
    723    Entity-header fields define metadata about the representation data
    724    enclosed in the message-body or, if no message-body is present, about
    725    the representation that would have been transferred in a 200 response
    726    to a simultaneous GET request on the Effective Request URI.
    727 </t>
    728 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-header"/><iref primary="true" item="Grammar" subitem="extension-header"/>
    729   <x:ref>entity-header</x:ref>  = <x:ref>Content-Encoding</x:ref>         ; <xref target="header.content-encoding"/>
    730                  / <x:ref>Content-Language</x:ref>         ; <xref target="header.content-language"/>
    731                  / <x:ref>Content-Length</x:ref>           ; &header-content-length;
    732                  / <x:ref>Content-Location</x:ref>         ; <xref target="header.content-location"/>
    733                  / <x:ref>Content-MD5</x:ref>              ; <xref target="header.content-md5"/>
    734                  / <x:ref>Content-Range</x:ref>            ; &header-content-range;
    735                  / <x:ref>Content-Type</x:ref>             ; <xref target="header.content-type"/>
    736                  / <x:ref>Expires</x:ref>                  ; &header-expires;
    737                  / <x:ref>Last-Modified</x:ref>            ; &header-last-modified;
    738                  / <x:ref>extension-header</x:ref>
    739  
    740   <x:ref>extension-header</x:ref> = <x:ref>header-field</x:ref>
    741 </artwork></figure>
    742 <t>
    743    The extension-header mechanism allows additional entity-header fields
    744    to be defined without changing the protocol, but these fields cannot
    745    be assumed to be recognizable by the recipient. Unrecognized header
    746    fields &SHOULD; be ignored by the recipient and &MUST; be forwarded by
    747    transparent proxies.
    748 </t>
     679<section title="Payload" anchor="payload">
     680<t>
     681   HTTP messages &MAY; transfer a payload if not otherwise restricted by
     682   the request method or response status code.  The payload consists of
     683   metadata, in the form of header fields, and data, in the form of the
     684   sequence of octets in the message-body after any transfer-coding has
     685   been decoded.
     686</t>
     687<iref item="payload"/>
     688<t>   
     689   A "<x:dfn>payload</x:dfn>" in HTTP is always a partial or complete
     690   representation of some resource.  We use separate terms for payload
     691   and representation because some messages contain only the associated
     692   representation's header fields (e.g., responses to HEAD) or only some
     693   part(s) of the representation (e.g., the 206 status code).
     694</t>
     695<t>
     696    define metadata for the whole representation, which we refer
     697   to as "representation header fields", while others define only metadata
     698   about what is included in the message, which we
     699</t>
     700<section title="Payload Header Fields" anchor="payload.header.fields">
     701  <x:anchor-alias value="payload-header"/>
     702<t>
     703   HTTP header fields that specifically define the payload, rather than the
     704   associated representation, are referred to as "payload header fields".
     705   The following payload header fields are defined by HTTP/1.1:
     706</t>
     707<figure><artwork>
     708   <x:ref>Content-Length</x:ref>           ; &header-content-length;
     709   <x:ref>Content-MD5</x:ref>              ; <xref target="header.content-md5"/>
     710   <x:ref>Content-Range</x:ref>            ; &header-content-range;
     711</artwork></figure>
    749712</section>
    750713
    751714<section title="Payload Body" anchor="payload.body">
    752715  <x:anchor-alias value="payload-body"/>
    753 <t>
    754    The payload body (if any) sent with an HTTP request or response is in
    755    a format and encoding defined by the entity-header fields.
    756 </t>
    757716<t>
    758717   A payload body is only present in a message when a message-body is
     
    761720   have been applied to ensure safe and proper transfer of the message.
    762721</t>
    763 
    764 <section title="Type" anchor="type">
    765 <t>
    766    When a payload body is included with a message, the data type of that
    767    body is determined via the header fields Content-Type and Content-Encoding.
     722</section>
     723</section>
     724
     725<section title="Representation" anchor="representation">
     726<iref item="representation"/>
     727<t>
     728   A "<x:dfn>representation</x:dfn>" is information in a format that can be readily
     729   communicated from one party to another.  A resource representation
     730   is information that reflects the state of that resource, as observed
     731   at some point in the past (e.g., in a response to GET) or to be
     732   desired at some point in the future (e.g., in a PUT request).
     733</t>
     734<t>
     735   Most, but not all, representations transferred via HTTP are intended
     736   to be a representation of the target resource (the resource identified
     737   by the effective request URI).  The precise semantics of a representation
     738   are determined by the type of message (request or response), the request
     739   method, the response status code, and the representation metadata.
     740   For example, the above semantic is true for the representation in any
     741   200 (OK) response to GET and for the representation in any PUT request.
     742   A 200 response to PUT, in contrast, contains either a representation
     743   that describes the successful action or a representation of the target
     744   resource, with the latter indicated by a Content-Location header field
     745   with the same value as the effective request URI.  Likewise, response
     746   messages with an error status code usually contain a representation that
     747   describes the error and what next steps are suggested for resolving it.
     748</t>
     749
     750<section title="Representation Header Fields" anchor="representation.header.fields">
     751  <x:anchor-alias value="representation-header"/>
     752<t>
     753   Representation header fields define metadata about the representation data
     754   enclosed in the message-body or, if no message-body is present, about
     755   the representation that would have been transferred in a 200 response
     756   to a simultaneous GET request with the same effective request URI.
     757</t>
     758<t>
     759   The following header fields are defined as representation metadata:
     760</t>
     761<figure><artwork>
     762   <x:ref>Content-Encoding</x:ref>         ; <xref target="header.content-encoding"/>
     763   <x:ref>Content-Language</x:ref>         ; <xref target="header.content-language"/>
     764   <x:ref>Content-Location</x:ref>         ; <xref target="header.content-location"/>
     765   <x:ref>Content-Type</x:ref>             ; <xref target="header.content-type"/>
     766   <x:ref>Expires</x:ref>                  ; &header-expires;
     767   <x:ref>Last-Modified</x:ref>            ; &header-last-modified;
     768</artwork></figure>
     769</section>
     770
     771<section title="Representation Data" anchor="representation.data">
     772  <x:anchor-alias value="representation-data"/>
     773<t>
     774   The representation body associated with an HTTP message is
     775   either provided as the payload body of the message or
     776   referred to by the message semantics and the effective request
     777   URI.  The representation data is in a format and encoding defined by
     778   the representation metadata header fields.
     779</t>
     780<t>
     781   The data type of the representation data
     782   is determined via the header fields Content-Type and Content-Encoding.
    768783   These define a two-layer, ordered encoding model:
    769784</t>
    770785<figure><artwork type="example">
    771   payload-body := Content-Encoding( Content-Type( data ) )
    772 </artwork></figure>
    773 <t>
    774    Content-Type specifies the media type of the underlying data. Any HTTP/1.1
    775    message containing a payload body &SHOULD; include a Content-Type header
    776    field defining the media type of that body, unless that information is
    777    unknown.
    778 </t>
    779 <t>   
     786  representation-data := Content-Encoding( Content-Type( bits ) )
     787</artwork></figure>
     788<t>
     789   Content-Type specifies the media type of the underlying data, which
     790   defines both the data format and how that data &SHOULD; be processed
     791   by the recipient (within the scope of the request method semantics).
     792   Any HTTP/1.1 message containing a payload body &SHOULD; include a
     793   Content-Type header field defining the media type of the associated
     794   representation unless that metadata is unknown to the sender.
    780795   If the Content-Type header field is not present, it indicates that
    781    the sender does not know the media type of the data; recipients &MAY;
    782    either assume that it is "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
     796   the sender does not know the media type of the representation;
     797   recipients &MAY; either assume that the media type is
     798   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    783799   or examine the content to determine its type.
    784800</t>
    785801<t>
    786    In practice, currently-deployed servers sometimes provide a Content-Type
    787    header which does not correctly convey the intended interpretation of the
    788    content sent, with the result that some clients will examine the response
    789    body's content and override the specified type.
    790 </t>
    791 <t>
     802   In practice, resource owners do not always properly configure their origin
     803   server to provide the correct Content-Type for a given representation,
     804   with the result that some clients will examine a response body's content
     805   and override the specified type.
    792806   Clients that do so risk drawing incorrect conclusions, which might expose
    793    additional security risks (e.g., "privilege escalation"). Implementers are
    794    encouraged to provide a means of disabling such "content sniffing" when it
    795    is used.
     807   additional security risks (e.g., "privilege escalation").  Furthermore,
     808   it is impossible to determine the sender's intent by examining the data
     809   format: many data formats match multiple media types that differ only in
     810   processing semantics.  Implementers are encouraged to provide a means of
     811   disabling such "content sniffing" when it is used.
    796812</t>
    797813<t>
    798814   Content-Encoding is used to indicate any additional content
    799815   codings applied to the data, usually for the purpose of data
    800    compression, that are a property of the representation.  There is
    801    no default encoding.
    802 </t>
    803 </section>
    804    
     816   compression, that are a property of the representation.  If
     817   Content-Encoding is not present, then there is no additional
     818   encoding beyond that defined by the Content-Type.
     819</t>
    805820</section>
    806821</section>
     
    962977   This section defines the syntax and semantics of HTTP/1.1 header fields
    963978   related to the payload of messages.
    964 </t>
    965 <t>
    966    For entity-header fields, both sender and recipient refer to either the
    967    client or the server, depending on who sends and who receives the message.
    968979</t>
    969980
     
    13091320  <x:anchor-alias value="Content-Encoding-v"/>
    13101321<t>
    1311    The "Content-Encoding" entity-header field indicates what content-codings
     1322   The "Content-Encoding" header field indicates what content-codings
    13121323   have been applied to the representation, and thus what decoding mechanisms
    13131324   must be applied in order to obtain the media-type referenced by the
     
    13591370  <x:anchor-alias value="Content-Language-v"/>
    13601371<t>
    1361    The "Content-Language" entity-header field describes the natural
     1372   The "Content-Language" header field describes the natural
    13621373   language(s) of the intended audience for the representation. Note that this might
    13631374   not be equivalent to all the languages used within the representation.
     
    14341445<t>
    14351446   If Content-Location is included in a response message and its value
    1436    is the same as the Effective Request URI, then the response payload
     1447   is the same as the effective request URI, then the response payload
    14371448   &SHOULD; be considered the current representation of that resource.
    14381449   For a GET or HEAD request, this is the same as the default semantics
     
    14461457<t>
    14471458   If Content-Location is included in a response message and its value
    1448    differs from the Effective Request URI, then the origin server is
     1459   differs from the effective request URI, then the origin server is
    14491460   informing recipients that this representation has its own, presumably
    14501461   more specific, identifier.  For a GET or HEAD request, this is an
    1451    indication that the Effective Request URI identifies a resource that
     1462   indication that the effective request URI identifies a resource that
    14521463   is subject to content negotiation and the representation selected for
    14531464   this response can also be found at the identified URI.  For other
     
    14911502</t>
    14921503<t>
    1493    If the Content-Location value is a partial URI, it is
    1494    interpreted relative to the Effective Request URI.
     1504   If the Content-Location value is a partial URI, the partial URI is
     1505   interpreted relative to the effective request URI.
    14951506</t>
    14961507</section>
     
    15021513  <x:anchor-alias value="Content-MD5-v"/>
    15031514<t>
    1504    The "Content-MD5" entity-header field, as defined in <xref target="RFC1864"/>, is
     1515   The "Content-MD5" header field, as defined in <xref target="RFC1864"/>, is
    15051516   an MD5 digest of the payload body that provides an end-to-end message
    15061517   integrity check (MIC) of the payload body (the message-body after any
     
    15771588  <x:anchor-alias value="Content-Type-v"/>
    15781589<t>
    1579    The "Content-Type" entity-header field indicates the media type of the
     1590   The "Content-Type" header field indicates the media type of the
    15801591   representation. In the case of responses to the HEAD method, the media type is
    15811592   that which would have been sent had the request been a GET.
     
    15921603</artwork></figure>
    15931604<t>
    1594    Further discussion of methods for identifying the media type of a
    1595    representation is provided in <xref target="type"/>.
     1605   Further discussion of Content-Type is provided in <xref target="representation.data"/>.
    15961606</t>
    15971607</section>
     
    28182828<x:ref>disposition-type</x:ref> = "attachment" / disp-extension-token
    28192829
    2820 <x:ref>entity-header</x:ref> = Content-Encoding / Content-Language / Content-Length
    2821  / Content-Location / Content-MD5 / Content-Range / Content-Type /
    2822  Expires / Last-Modified / extension-header
    2823 <x:ref>extension-header</x:ref> = header-field
    2824 
    28252830<x:ref>filename-parm</x:ref> = "filename=" quoted-string
    28262831
     
    28572862; MIME-Version defined but not used
    28582863; content-disposition defined but not used
    2859 ; entity-header defined but not used
    28602864</artwork></figure></section>
    28612865<?ENDINC p3-payload.abnf-appendix ?>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r960 r965  
    312312  <x:anchor-alias value="weak"/>
    313313<t>
    314    Entity-tags are used for comparing two or more representations from the same
    315    requested resource. HTTP/1.1 uses entity-tags in the ETag (<xref target="header.etag"/>),
     314   Entity-tags are used for comparing two or more representations of the same
     315   resource. HTTP/1.1 uses entity-tags in the ETag (<xref target="header.etag"/>),
    316316   If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
    317317   If-Range (&header-if-range;) header fields. The definition of how they
     
    725725   related to conditional requests.
    726726</t>
    727 <t>
    728    For entity-header fields, both sender and recipient refer to either the
    729    client or the server, depending on who sends and who receives the message.
    730 </t>
    731727
    732728<section title="ETag" anchor="header.etag">
     
    738734   The "ETag" response-header field provides the current value of the
    739735   entity-tag (see <xref target="entity.tags"/>) for one representation of
    740    the resource identified by the Effective Request URI.  An entity-tag
     736   the resource identified by the effective request URI.  An entity-tag
    741737   is intended for use as a resource-local identifier for differentiating
    742738   between representations of the same resource that vary over time or via
     
    10581054  <x:anchor-alias value="Last-Modified-v"/>
    10591055<t>
    1060    The "Last-Modified" entity-header field indicates the date and time at
     1056   The "Last-Modified" header field indicates the date and time at
    10611057   which the origin server believes the representation was last modified.
    10621058</t>
     
    10981094</t>
    10991095<t>
    1100    The Last-Modified entity-header field value is often used as a cache
     1096   The Last-Modified header field value is often used as a cache
    11011097   validator. In simple terms, a cache entry is considered to be valid
    11021098   if the representation has not been modified since the Last-Modified value.
  • draft-ietf-httpbis/latest/p5-range.xml

    r962 r965  
    397397<t>
    398398   If the 206 response is the result of an If-Range request, the response
    399    &SHOULD-NOT; include other entity-headers. Otherwise, the response
    400    &MUST; include all of the entity-headers that would have been returned
     399   &SHOULD-NOT; include other representation header fields. Otherwise, the response
     400   &MUST; include all of the representation header fields that would have been returned
    401401   with a 200 (OK) response to the same request.
    402402</t>
     
    428428<t>
    429429   When this status code is returned for a byte-range request, the
    430    response &SHOULD; include a Content-Range entity-header field
    431    specifying the current length of the selected resource (see <xref target="header.content-range"/>).
     430   response &SHOULD; include a Content-Range header field
     431   specifying the current length of the representation (see <xref target="header.content-range"/>).
    432432   This response &MUST-NOT; use the multipart/byteranges content-type.
    433433</t>
     
    467467   This section defines the syntax and semantics of HTTP/1.1 header fields
    468468   related to range requests and partial responses.
    469 </t>
    470 <t>
    471    For entity-header fields, both sender and recipient refer to either the
    472    client or the server, depending on who sends and who receives the message.
    473469</t>
    474470
     
    523519  <x:anchor-alias value="other-range-resp-spec"/>
    524520<t>
    525    The "Content-Range" entity-header field is sent with a partial representation to
    526    specify where in the full representation the partial body should be
     521   The "Content-Range" header field is sent with a partial representation to
     522   specify where in the full representation the payload body should be
    527523   applied.
    528524</t>
     
    16321628    <t>
    16331629      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
    1634       "Clarify entity / representation / variant terminology"
    1635     </t>
    1636     <t>
    1637       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
    16381630      "consider removing the 'changes from 2068' sections"
    16391631    </t>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r951 r965  
    504504   unless:
    505505   <list style="symbols">
    506       <t>The presented Effective Request URI (&effective-request-uri;) and
     506      <t>The presented effective request URI (&effective-request-uri;) and
    507507      that of the stored response match, and</t>
    508508      <t>the request method associated with the stored response allows it to
     
    868868   An invalidation based on a URI from a Location or Content-Location header
    869869   &MUST-NOT; be performed if the host part of that URI differs from the host
    870    part in the Effective Request URI (&effective-request-uri;). This helps
     870   part in the effective request URI (&effective-request-uri;). This helps
    871871   prevent denial of service attacks.
    872872</t>
    873873<t>
    874874   A cache that passes through requests for methods it does not understand
    875    &SHOULD; invalidate the Effective Request URI (&effective-request-uri;).
     875   &SHOULD; invalidate the effective request URI (&effective-request-uri;).
    876876</t>
    877877<t>
    878878   Here, "invalidate" means that the cache will either remove all stored
    879    responses related to the Effective Request URI, or will mark these as
     879   responses related to the effective request URI, or will mark these as
    880880   "invalid" and in need of a mandatory validation before they can be returned
    881881   in response to a subsequent request.
     
    10101010   related to caching.
    10111011</t>
    1012 <t>
    1013    For entity-header fields, both sender and recipient refer to either the
    1014    client or the server, depending on who sends and who receives the message.
    1015 </t>
    10161012
    10171013<section anchor="header.age" title="Age">
     
    14351431   <x:anchor-alias value="Expires-v"/>
    14361432<t>
    1437    The "Expires" entity-header field gives the date/time after which the
     1433   The "Expires" header field gives the date/time after which the
    14381434   response is considered stale. See <xref target="expiration.model" /> for
    14391435   further discussion of the freshness model.
     
    26082604  <list style="symbols">
    26092605    <t>
     2606      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
     2607      "Clarify entity / representation / variant terminology"
     2608    </t>
     2609    <t>
    26102610      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
    26112611      "consider removing the 'changes from 2068' sections"
  • draft-ietf-httpbis/latest/p7-auth.xml

    r961 r965  
    303303   The request requires user authentication. The response &MUST; include a
    304304   WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
    305    applicable to the requested resource. The client &MAY; repeat the
     305   applicable to the target resource. The client &MAY; repeat the
    306306   request with a suitable Authorization header field (<xref target="header.authorization"/>). If
    307307   the request already included Authorization credentials, then the 401
     
    323323   client must first authenticate itself with the proxy. The proxy &MUST;
    324324   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
    325    challenge applicable to the proxy for the requested resource. The
     325   challenge applicable to the proxy for the target resource. The
    326326   client &MAY; repeat the request with a suitable Proxy-Authorization
    327327   header field (<xref target="header.proxy-authorization"/>). HTTP access authentication is explained
     
    402402   The "Proxy-Authenticate" response-header field consists of a challenge that
    403403   indicates the authentication scheme and parameters applicable to the proxy
    404    for this Effective Request URI (&effective-request-uri;). It &MUST; be included as part
     404   for this effective request URI (&effective-request-uri;). It &MUST; be included as part
    405405   of a 407 (Proxy Authentication Required) response.
    406406</t>
     
    461461   The "WWW-Authenticate" response-header field consists of at least one
    462462   challenge that indicates the authentication scheme(s) and parameters
    463    applicable to the Effective Request URI (&effective-request-uri;). It &MUST; be included in 401
     463   applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401
    464464   (Unauthorized) response messages.
    465465</t>
Note: See TracChangeset for help on using the changeset viewer.