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

I'm confiused.  This doesn't look anything like HTTP to me.

Servers don't send methods

Also why would you want to break every CONNECT implementation on the 
planet?  It's in very widespread use.


On 1/06/2011 8:19 a.m., Dzonatas Sol wrote:
> Addendum apropos idempotent sanity:
>
> The first http CONNECT method may exit with status=100 and (since 200 
> is indeterminate state before) the second same CONNECT method may exit 
> with status=101 while the state (200 is then determinate by 
> consistency of state in GET methods) of that connection issues an 
> immediate status=203 upon GET method for internal sources and any 
> appropriate action for external resources (that expect normals).
>
> That logical helps separate transient data with cache data due to 
> virtualization of GET localization (or normalization) upon the event 
> of status=101.
>
> Imperfect outer state, for these transistions, that is perfect for 
> inner stateful transfers. The above does not force an opened or closed 
> overall state; therefore, sanitization implies tail compression.
>
> On 05/31/2011 09:38 AM, Dzonatas Sol wrote:
>> 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
>>>>
>>>
>>>
>>
>>
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 31 May 2011 23:00:36 UTC