Re: Status Code 203

Thanks Francois. I think that since 203 does not tell the recipient 
anything they do not know already in the use case you discuss, and since 
RFC 2616 says nothing about this being appropriate let alone mandated to 
proxy operation, we assign this issue to a (virtual) footnote of the 
history of content transformation.

Jo

On 01/04/2010 16:33, Francois Daoust wrote:
> Hi guys,
>
> I took ACTION-1047 on Tuesday to investigate a bit more on the HTTP
> status code 203.
>
> The status code 203 [1] basically means: "I cannot serve the original
> content, so I'm serving a copy gathered from somewhere else which should
> do the trick except it's not authoritative". Applied to the Guidelines
> for Web Content Transformation Proxies, one way to view the CT proxy is
> to say that it is serving a local copy of the response that is not the
> original one.
>
> The status code 203 may be considered a good fit for our purpose.
>
> It could be used:
>
> 1. to advertise modifications made to the HTTP response. But that's
> neither really needed nor a valid use case of this status code: proxies
> already must add a Warning 214 Transformation Applied when the response
> is modified, and the definition of status code 203 only mentions "the
> returned metainformation in the *entity-header*" for some reason and
> we're more talking about transformation of the entity-body.
>
> 2. to advertise that the returned HTTP response may not be the one that
> would have been served had the HTTP request not been modified. That
> would be a good thing to have, although one might perhaps argue that it
> would be stretching the definition of the 203 status code a little bit
> (we're not exactly considering modifications of the entity-header but
> rather complete replacement of the entity-header and entity-body).
>
> In short, 1. is not a good use case, 2. is.
>
> One possible guideline for using status code 203 could be something
> along the lines of:
> [[
> Proxies SHOULD modify the status code of the HTTP response to 203 when
> the original status code is 200 and the HTTP request that lead to this
> HTTP response has been modified as defined in 4.1.5.
> ]]
>
> The main benefit would be the possibility for a client to detect that
> the response may not be the original one even when the proxy has "only"
> modified the HTTP request. The obvious drawback is that adding the
> guideline would require the publication of a fourth Last Call and might
> trigger new comments. I am not sure that it is worth it in the end, i.e.
> the client would not be able to tell whether the response is really
> different from what the original response would have been, and that
> uncertainty can already be gathered from the "Via" HTTP header as
> defined in 4.1.6.1 [2]
>
> Francois.
>
>
> [1]
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-09#section-8.2.4
> [2] http://www.w3.org/TR/ct-guidelines/#sec-via-headers
>

Received on Thursday, 1 April 2010 17:28:03 UTC