You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/11/03 03:48:30 UTC
svn commit: r591544 - in /labs/webarch/trunk/http/draft-fielding-http:
p1-messaging.html p1-messaging.xml p3-payload.html p3-payload.xml
Author: fielding
Date: Fri Nov 2 19:48:30 2007
New Revision: 591544
URL: http://svn.apache.org/viewvc?rev=591544&view=rev
Log:
Resolve [LABS-18]: [i16] Remove 'identity' token references
Modified:
labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml
labs/webarch/trunk/http/draft-fielding-http/p3-payload.html
labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml
Modified: labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html?rev=591544&r1=591543&r2=591544&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html Fri Nov 2 19:48:30 2007
@@ -1071,7 +1071,7 @@
in determining the exact body length (<a href="#message.length" title="Message Length">Section 4.4</a>), or the desire to encrypt data over a shared transport.
</p>
<p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry
- contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "identity" (section 3.6.2), "gzip" ([Part 3]), "compress" ([Part 3]), and "deflate" ([Part 3]).
+ contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip" ([Part 3]), "compress" ([Part 3]), and "deflate" ([Part 3]).
</p>
<p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens ([Part 3]).
</p>
@@ -1214,8 +1214,7 @@
</p>
</li>
<li>
- <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.7</a>) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding
- (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), unless the message is terminated by closing the connection.
+ <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.7</a>) is present, then the transfer-length is defined by use of the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), unless the message is terminated by closing the connection.
</p>
</li>
<li>
@@ -1247,8 +1246,7 @@
</p>
<p id="rfc.section.4.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
</p>
- <p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity
- transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.
+ <p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.
</p>
<p id="rfc.section.4.4.p.6">When a Content-Length is given in a message where a message-body is allowed, its field value <em class="bcp14">MUST</em> exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents <em class="bcp14">MUST</em> notify the user when an invalid length is received and detected.
</p>
Modified: labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml?rev=591544&r1=591543&r2=591544&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml Fri Nov 2 19:48:30 2007
@@ -1142,9 +1142,8 @@
<t>
The Internet Assigned Numbers Authority (IANA) acts as a registry for
transfer-coding value tokens. Initially, the registry contains the
- following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>), "identity" (section
- 3.6.2), "gzip" (&payload;), "compress" (&payload;), and "deflate"
- (&payload;).
+ following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>),
+ "gzip" (&payload;), "compress" (&payload;), and "deflate" (&payload;).
</t>
<t>
New transfer-coding value tokens &SHOULD; be registered in the same way
@@ -1404,8 +1403,8 @@
the message.
</t></x:lt>
<x:lt><t>
- If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>) is present and
- has any value other than "identity", then the transfer-length is
+ If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>)
+ is present, then the transfer-length is
defined by use of the "chunked" transfer-coding (<xref target="transfer.codings"/>),
unless the message is terminated by closing the connection.
</t></x:lt>
@@ -1457,7 +1456,7 @@
</t>
<t>
Messages &MUST-NOT; include both a Content-Length header field and a
- non-identity transfer-coding. If the message does include a non-identity
+ transfer-coding. If the message does include a
transfer-coding, the Content-Length &MUST; be ignored.
</t>
<t>
Modified: labs/webarch/trunk/http/draft-fielding-http/p3-payload.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p3-payload.html?rev=591544&r1=591543&r2=591544&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p3-payload.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p3-payload.html Fri Nov 2 19:48:30 2007
@@ -1301,9 +1301,7 @@
a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045).
</p>
<h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2>
- <p id="rfc.section.A.4.p.1">HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols
- to HTTP <em class="bcp14">MUST</em> remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP
- client.
+ <p id="rfc.section.A.4.p.1">HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
</p>
<p id="rfc.section.A.4.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct
format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol
Modified: labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml?rev=591544&r1=591543&r2=591544&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml Fri Nov 2 19:48:30 2007
@@ -2046,9 +2046,9 @@
<section title="No Content-Transfer-Encoding" anchor="no.content-transfer-encoding">
<t>
- HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
+ HTTP does not use the Content-Transfer-Encoding field of RFC
2045. Proxies and gateways from MIME-compliant protocols to HTTP &MUST;
- remove any non-identity CTE ("quoted-printable" or "base64") encoding
+ remove any Content-Transfer-Encoding
prior to delivering the response message to an HTTP client.
</t>
<t>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org