- From: Francois Daoust <fd@w3.org>
- Date: Thu, 01 Apr 2010 17:33:24 +0200
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
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 15:33:55 UTC