9.9 CONNECT (Re: 203 Non-Authoritative Information: deprecate?)

RFC2116 indicates the CONNECT method is reserved, 
<http://www.ietf.org/rfc/rfc2616.txt>:

9.9 CONNECT

    This specification reserves the method name CONNECT for use with a
    proxy that can dynamically switch to being a tunnel (e.g. SSL
    tunneling [44]).


There is an assumption made how that tunnel is implemented. That would 
be much more extensible if we expect "Content-Type:" instead of that 
tunnel assumption, especially given 
<http://www.ietf.org/rfc/rfc2634.txt> (S/MIME).

For example, let this *request* initialize one persistent client/server 
object that did not previously exist:

 > CONNECT /000
 > Content-Type: multipart/mixed; boundary=stream
 > Content-Length: 0
 >
 > --stream
 > Content-Type: xml-ietf-http/1.1; method=head; prefix="/.well-known/"
 > Content-Length: 0
 >
 > --stream

Instead of the proxy or tunnel (described in 9.9), the above could bind 
two queues (i.e. local and remote) together as one logical stream. I 
thought about the GET only server, yet the above appears more practical, 
as every GET succeeds the HEAD.

The *response* could look like (in Turing-complete manner):

 > CONNECT /000
 > Content-Type: multipart/mixed; boundary=STREAM000
 > Content-Length: 0
 >
 > --STREAM000
 >   Content-Disposition: head
 >
 > --STREAM000
 >   Content-Type: xml-ietf-http/1.1; method=post; 
prefix="/.well-known/"; filename="browser-hints"; format=json
 >
 >   {
 >      "max-conns": 1,
 >      "small-hdrs": true
 >      "omit-cookies": true
 >    }
 >
 > --STREAM000
 >   Content-Disposition: body
 >
 > --STREAM000
 >   Content-Type: xml-ietf-http/1.1; method=put; 
filename="browser-hints"; format=json
 >
 >    {
 >      "omit-cookies": [
 >         ["/images/users/", false],
 >         ["/images/", true]
 >         ]
 >     }
 >
 > --STREAM000
 >   Content-Disposition: tail
 >
 > --STREAM000
 > Content-Type: xml-ietf-http/1.1; method=delete; 
prefix="/.well-known/"; filename="browser-hints"
 > Content-Length: 0
 >
 > --STREAM000--


The most significant bit is that both the client and server issue the 
same exact CONNECT method.



On 05/30/2011 12:43 PM, Dzonatas Sol wrote:
> Status code 203 is more appropriate for the GET method while 214 is 
> more appropriate for the POST, PUT, and DELETE methods.
>
> If there are several POST, PUT, and DELETE operations on the queue 
> that expect the same definitive set of headers, 214 could indicate the 
> simple merge of each query was made into multi-part mime format (i.e. 
> where content-type now indicates the method) instead of individual 
> connections/queries. 214 status can include GET in the same way, yet I 
> think of the 203 status as an optimization in strict queries that 
> simply convey "there is no know cause why anything changed about the 
> original message".
>
>
> On 05/30/2011 11:28 AM, Roy T. Fielding wrote:
>> On May 29, 2011, at 6:27 PM, Mark Nottingham wrote:
>>
>>> Hmm. I see that we have warn code 214, "Transformation applied," 
>>> which makes me wonder about the relationship (whether or not we go 
>>> with the proposal below).
>> The 203 status was defined in 1993 (IIRC) and later implemented in 
>> proxies like
>> Commentor (IIRC).  I don't know if anything depends on it today, but 
>> it is
>> known and usable by Apache httpd.
>>
>> Warnings were added in 1996 and, AFAIK, only implemented for the 
>> purpose of
>> server-side RFC compliance.  Apache httpd's mod_filter adds it while 
>> filtering
>> content as a proxy (it does not set 203 because it can filter error 
>> content,
>> though I could change that if some other checks in the code are fixed).
>>
>> I do not know of any clients that check for either one, since there 
>> isn't
>> much they can do about it.
>>
>> ....Roy
>>
>
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

Received on Tuesday, 31 May 2011 16:40:37 UTC