Subject: 203 Non-Authoritative Information: deprecate?

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 May 2011 15:14:04 +1000

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#section-8.2.4

Does anyone know of software that actually does something useful with this status code?

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 28 May 2011 11:46:12 -0700

203 is an appropriate reply for origin servers that do not accept 
cookies or want to apply such strictness (or alertness) other than 
simply ignore such headers. It may be harder to pinpoint software that 
actively uses it other than for backward compatibility or tolerance of 
header style metadata.

No on deprecate because that is appropriate for origin servers' 
recognition of such information. UA could simply say, "I didn't require 
or request any extra metadata, so 203 means don't use the request, don't 
reply to the query, and do appropriate error." Whereas, the 
application(U) just turns 203 into 200 for greater compatibility.

Message queues is one example of such UA. People "should" use some sort 
of message queue, or similar UA database, instead of cookies.

In re: 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02716.html

There could be the hint for "status-203" to trigger an error (409) 
instead of compatibility (200). (Also apropos to UK's anti-cookie law.)

I'm glad you brought this up because I wondered yesterday how-to enforce 
the simple GET/PUT with no extra headers. The intent would be to 
tokenize the entire header data as one single packet that could be 
stored as session data in the UA, given any UUID. That is logically the 
same as header compression, especially if out of all queries the only 
difference is body content and resource path. That could further let the 
entire tokenized header into private URLs: "GET 
/Header-UUID/Private-UUID/(XPath)..." and where the message is "simply" 
XHTML.

The stateless/stateful debate I think has delayed such usage of private 
URLs and UAs. One reason why SOCKS5 still has support... mystery why 
it's not more standard in regards to TLS and hypermedia.

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

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 28 May 2011 12:55:53 -0700

On 05/28/2011 11:46 AM, Dzonatas Sol wrote:
> That could further let the entire tokenized header into private URLs: 
> "GET /Header-UUID/Private-UUID/(XPath)..." and where the message is 
> "simply" XHTML.
>
>

I should back-up one step and give an example in streamed connections:

GET /Connection-UUID/Header-UUID(/XPath)... HTTP/1.0
or decompiled to:
GET /Connection-UUID/Header-UUID(/XPath)... XHTML/1.0

I'm glad you put "max-conns" in then we can pre-set the Connection-UUIDs 
http://www.ietf.org/id/draft-nottingham-http-browser-hints-01.txt with a 
POST context to the UA.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 29 May 2011 09:07:21 -0700

This now makes an interesting case, today. If ISPs enforce maximum data 
limits per month (not just bandwidth), then what part is their 
responsibility to use protocols that make effective use of the given 
bitstreams? I think ISPs would want to implement 203 in order to opt-out 
of any cause that increases header size or opt-out of causes that would 
otherwise not keep the header data immutable as possible.

That opens the debate where there are any imposed data limits and the 
203 occurs such that the excess 'non-authoritative information' falls 
into liabilities. Do people pay for authoritative usage? Are there any 
specific ISP directive that deems "only allow authoritative 
information", especially if the end-user is being held liable for such 
usage by the ISP.

The 200 could indicate the header usage is idempotent, yet anything 
added after the origin server would need to reply with 203 (except maybe 
hops through DNSSEC). I chose this way to speak-up about this rather 
then the details of many of possible liabilities (like when the response 
should be 203 instead of 200), especially in consideration of power 
consumption, efficiency, sustainability, and emergency response.

That is only some of the reasons why I pointed out the earlier method of 
header tokenization. (Now, if there is some clear idempotent way to 
reuse that header token such that parses well with extra authoritative 
information like alignment in media fragment headers...)

On 05/28/2011 12:55 PM, Dzonatas Sol wrote:
> I'm glad you put "max-conns" in 
> http://www.ietf.org/id/draft-nottingham-http-browser-hints-01.txt so 
> we can pre-set the Connection-UUIDs  with a POST context to the UA.
>

--

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 29 May 2011 12:51:55 -1000

> Does anyone know of software that actually does something useful with this status code?

203 is for annotation proxies and other intermediaries that add something to
the response.  It is the only way to indicate that contents have changed from
the origin's response, which may be important for sigs/MACs, so I would not
want to deprecate it.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 May 2011 09:25:17 +1000

> the origin's response, which may be important for sigs/MACs, so I would not

OK. I'd like to clarify it so that this is more apparent; i.e., the semantic is "this has been transformed" (perhaps linking it into no-transform's semantics), because I've seen some people interpret this as "it's a cached response."

Will come up with a proposal.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 May 2011 10:31:25 +1000

Current:

"""
8.2.4.  203 Non-Authoritative Information

The returned metadata in the header fields is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy.  The set presented MAY be a subset or superset of the original version.  For example, including local annotation information about the resource might result in a superset of the metadata known by the origin server.  Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).

Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to determine freshness for 203 responses.
"""

Proposed:

"""
8.2.4.  203 Non-Authoritative Information

The representation in the response has been transformed or otherwise modified by a non-transparent proxy [ref to p1].  Note that the behaviour of non-transparent intermediaries is controlled by the no-transform Cache-Control dirctive [ref to p6].

This status code is only appropriate when the response status code would have been 200 (OK).

Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to determine freshness for 203 responses.
"""

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 May 2011 14:27:23 +1000

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 30 May 2011 08:28:00 -1000

> 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

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 30 May 2011 12:43:55 -0700

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

--

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 May 2011 14:42:18 +1000

Revised proposal:

"""

This status code is only appropriate when the response status code would have been 200 (OK). When the status code before transformation would have been
different, the 214 Transformation Applied warn-code [ref] is appropriate.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 May 2011 09:16:36 +0200

> The representation in the response has been transformed or otherwise modified by a non-transparent proxy [ref to p1].  Note that the behaviour of non-transparent intermediaries is controlled by the…

Part 1 uses the terms transforming-/non-transforming proxy 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-14.html#intermediaries>).

Maybe also say "transforming intermediaries" instead no "transparent 
intermediaries"?

> Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to determine freshness for 203 responses.

I feel this is actually a *change* compared to 2616 (the spec, not the 
actual practice); thus we may have to list it in the Changes appendix.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 May 2011 18:08:49 +1000

Agreed on both counts. Now #296:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/296

On 31/05/2011, at 5:16 PM, Julian Reschke wrote:

> Part 1 uses the terms transforming-/non-transforming proxy (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-14.html#intermediaries>).
> 
> Maybe also say "transforming intermediaries" instead no "transparent intermediaries"?
> 
> I feel this is actually a *change* compared to 2616 (the spec, not the actual practice); thus we may have to list it in the Changes appendix.
> 
> Best regards, Julian

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 31 May 2011 09:38:53 -0700

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 
> 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".
>
>
>>> 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).

--

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 31 May 2011 13:19:09 -0700

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:
> For example, let this *request* initialize one persistent 
> client/server object that did not previously exist:
>
> > CONNECT /000
> 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.
>
>> 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".
>>
>>

--

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 01 Jun 2011 11:00:02 +1200

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:
> 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).
>
> 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.
>
>> 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 

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