Skip to content

Commit

Permalink
Merge pull request #283 from httpwg/mnot-111
Browse files Browse the repository at this point in the history
Header terminology (#111)
  • Loading branch information
reschke authored Feb 3, 2020
2 parents 721faf8 + c322330 commit 05aeac0
Show file tree
Hide file tree
Showing 5 changed files with 751 additions and 737 deletions.
50 changes: 25 additions & 25 deletions draft-ietf-httpbis-cache-latest.xml
Original file line number Diff line number Diff line change
Expand Up @@ -933,7 +933,7 @@
(<xref target="header.if-none-match"/>) indicates that the client wants to validate one
or more of its own stored responses in comparison to whichever stored
response is selected by the cache.
If the field-value is "*", or if the field-value is a list of entity-tags
If the field value is "*", or if the field value is a list of entity-tags
and at least one of them matches the entity-tag of the selected stored
response, a cache recipient &SHOULD; generate a
<x:ref>304 (Not Modified)</x:ref> response (using the metadata of the
Expand Down Expand Up @@ -965,9 +965,9 @@
response (using the metadata of the selected stored response) if one of the
following cases is true:
1) the selected stored response has a <x:ref>Last-Modified</x:ref>
field-value that is earlier than or equal to the conditional timestamp;
field value that is earlier than or equal to the conditional timestamp;
2) no <x:ref>Last-Modified</x:ref> field is present in the selected stored
response, but it has a <x:ref>Date</x:ref> field-value that is earlier than
response, but it has a <x:ref>Date</x:ref> field value that is earlier than
or equal to the conditional timestamp; or,
3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present
in the selected stored response, but the cache recorded it as having been
Expand Down Expand Up @@ -1129,17 +1129,17 @@



<section title="Header Field Definitions" anchor="header.field.definitions">
<section title="Field Definitions" anchor="header.field.definitions">
<t>
This section defines the syntax and semantics of HTTP header fields
This section defines the syntax and semantics of HTTP fields
related to caching.
</t>
<?BEGININC build/draft-ietf-httpbis-cache-latest.iana-headers ?>
<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
<table align="left" anchor="iana.header.registration.table">
<thead>
<tr>
<th>Header Field Name</th>
<th>Field Name</th>
<th>Status</th>
<th>Reference</th>
</tr>
Expand Down Expand Up @@ -1200,7 +1200,7 @@
<x:ref>Age</x:ref> = <x:ref>delta-seconds</x:ref>
</sourcecode>
<t>
The Age field-value is a non-negative integer, representing time in seconds
The Age field value is a non-negative integer, representing time in seconds
(see <xref target="delta-seconds"/>).
</t>
<t>
Expand Down Expand Up @@ -1525,17 +1525,17 @@
been configured to send stale responses.
</t>
<t>
If the no-cache response directive specifies one or more field-names,
If the no-cache response directive specifies one or more field names,
then a cache &MAY; use the response to satisfy a subsequent request,
subject to any other restrictions on caching. However, any header fields
in the response that have the field-name(s) listed &MUST-NOT; be sent
in the response that have the field name(s) listed &MUST-NOT; be sent
in the response to a subsequent request without successful revalidation
with the origin server. This allows an origin server to prevent the
re-use of certain header fields in a response, while still allowing
caching of the rest of the response.
</t>
<t>
The field-names given are not limited to the set of header
The field names given are not limited to the set of header
fields defined by this specification. Field names are case-insensitive.
</t>
<t>
Expand All @@ -1546,7 +1546,7 @@
<t>
&Note; Although it has been back-ported to many implementations, some
HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache
response directives with field-names are often handled by caches
response directives with field names are often handled by caches
as if an unqualified no-cache directive was received; i.e., the special
handling for the qualified form is not widely implemented.
</t>
Expand Down Expand Up @@ -1613,14 +1613,14 @@
even if the response would normally be non-cacheable.
</t>
<t>
If the private response directive specifies one or more field-names,
this requirement is limited to the field-values associated with the
If the private response directive specifies one or more field names,
this requirement is limited to the field values associated with the
listed response header fields. That is, a shared cache &MUST-NOT; store
the specified field-names(s), whereas it &MAY; store the remainder of the
the specified field names(s), whereas it &MAY; store the remainder of the
response message.
</t>
<t>
The field-names given are not limited to the set of header
The field names given are not limited to the set of header
fields defined by this specification. Field names are case-insensitive.
</t>
<t>
Expand All @@ -1631,7 +1631,7 @@
<t>
&Note; This usage of the word "private" only controls
where the response can be stored; it cannot ensure the privacy of the
message content. Also, private response directives with field-names are
message content. Also, private response directives with field names are
often handled by caches as if an unqualified private directive
was received; i.e., the special handling for the qualified form is not
widely implemented.
Expand Down Expand Up @@ -1811,7 +1811,7 @@
with a reliable clock.
</t>
<t>
Historically, HTTP required the Expires field-value to be no more than a
Historically, HTTP required the Expires field value to be no more than a
year in the future. While longer freshness lifetimes are no longer
prohibited, extremely large values have been demonstrated to cause
problems (e.g., clock overflows due to use of 32-bit integers for
Expand Down Expand Up @@ -1963,12 +1963,12 @@
"IETF ([email protected]) - Internet Engineering Task Force".
</t>

<section title="Header Field Registration" anchor="header.field.registration">
<section title="Field Registration" anchor="header.field.registration">
<t>
Please update the "Hypertext Transfer Protocol (HTTP) Header Field
Please update the "Hypertext Transfer Protocol (HTTP) Field
Registry" registry at <eref
target="https://www.iana.org/assignments/http-headers"/> with the
header field names listed in the two tables of <xref
target="https://www.iana.org/assignments/http-fields"/> with the
field names listed in the two tables of <xref
target="header.field.definitions"/>.
</t>
</section>
Expand Down Expand Up @@ -2252,17 +2252,17 @@

<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, see <xref target="Semantics" x:fmt="," x:sec="10.1.1.1"/>&gt;

<x:ref>OWS</x:ref> = &lt;OWS, see <xref target="Semantics" x:fmt="," x:sec="4.3"/>&gt;
<x:ref>OWS</x:ref> = &lt;OWS, see <xref target="Semantics" x:fmt="," x:sec="11.1"/>&gt;

<x:ref>cache-directive</x:ref> = token [ "=" ( token / quoted-string ) ]

<x:ref>delta-seconds</x:ref> = 1*DIGIT

<x:ref>field-name</x:ref> = &lt;field-name, see <xref target="Semantics" x:fmt="," x:sec="4.2"/>&gt;
<x:ref>field-name</x:ref> = &lt;field-name, see <xref target="Semantics" x:fmt="," x:sec="4.3"/>&gt;

<x:ref>quoted-string</x:ref> = &lt;quoted-string, see <xref target="Semantics" x:fmt="," x:sec="4.2.3"/>&gt;
<x:ref>quoted-string</x:ref> = &lt;quoted-string, see <xref target="Semantics" x:fmt="," x:sec="4.4.1.2"/>&gt;

<x:ref>token</x:ref> = &lt;token, see <xref target="Semantics" x:fmt="," x:sec="4.2.3"/>&gt;
<x:ref>token</x:ref> = &lt;token, see <xref target="Semantics" x:fmt="," x:sec="4.4.1.1"/>&gt;
</sourcecode>
</section>
<?ENDINC build/draft-ietf-httpbis-cache-latest.abnf-appendix ?>
Expand Down
Loading

0 comments on commit 05aeac0

Please sign in to comment.