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

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
>>>
>>
>>
>
>


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

Received on Tuesday, 31 May 2011 20:20:51 UTC