- From: Mark Baker <distobj@acm.org>
- Date: Fri, 20 Nov 2009 11:32:29 -0500
- To: fd@w3.org
- Cc: public-bpwg-comments@w3.org
Francois, these are the only follow-on comments I have. Thanks. On Tue, Oct 6, 2009 at 10:34 AM, <fd@w3.org> wrote: > Your comment on 4.1.1 Applicable HTTP Methods: >> 4.1.1 Applicable HTTP Methods >> >> "Proxies should not intervene in methods other than GET, POST, HEAD and >> PUT." >> >> I can't think of any good reason for that. If a request using an >> extension method wants to avoid transformation, it can always include >> the no-transform directive. > > > Working Group Resolution (LC-2034): > This "should not" note shows the scope of Content Transformation as > discussed in the Guidelines Recommendation. It is not envisaged that a > content transformation proxy will intervene in a HTTP CONNECT for example. > Or that a content transformation proxy will transform anything in any > WebDAV methods. In fact we don't envisage any intervention in PUT either, > so we will drop this to clarify that the scope of the document is limited > to web browsing, using GET, POST & HEAD requests and their responses. > > The updated text is available at: > http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-applicable-HTTP-methods IMO, that's even worse. Excluding methods on the basis that the group doesn't currently see a need, is destined to come back to haunt you - and followers of the guidelines - in the future. What if a compelling use case arises in a few years time? Oops! IMO, unless harm is caused by not disallowing it, it shouldn't be disallowed. I can see no harm caused by not calling out any method, except CONNECT, though it would be useful to go through the list of currently registered HTTP methods to see if there's any others. Specifically, I can imagine several scenarios where transforming PUT requests or responses would be useful. > > ---- > > Your comment on 4.1.5 Alteration of HTTP Header Values: >> 4.1.5 Alteration of HTTP Header Values >> >> RFC 2616 already says a lot about this. See sec 13.5.2 for example. >> >> "The theoretical idempotency of GET requests is not always respected >> by servers. In order, as far as possible, to avoid mis-operation of >> such content, proxies should avoid issuing duplicate requests and >> specifically should not issue duplicate requests for comparison >> purposes." >> >> First of all, do you mean "safe" or "idempotent"? That you refer only >> to GET suggests safety, but the second sentence suggests you are >> referring to idempotency. So please straighten that out. Oh, and >> there's nothing "theoretical" about GET's safety or idempotency; it's >> by definition, in fact. >> >> Secondly, if the server changes something important because it >> received a GET request, then that's its problem. Likewise, if it >> changes something non-idempotently because it received a PUT request, >> that's also something it has to deal with. In both cases though, the >> request itself is idempotent (and safe with GET), so I see no merit to >> that advice that you offer ... unless of course the problem you refer >> to is pervasive which clearly isn't the case. >> >> I also wonder if most of 4.1.5 shouldn't just defer to 2616. As is, >> large chunks of this section (as well as others) specify a protocol >> which is a subset of HTTP 1.1. (see also the RFC 2119 comment above) > > > Working Group Resolution (LC-2036): > Based on our experience and feedback from servers whose operators take > strong exception to the practice of repeating GETs, we think it is > reasonable to advise content transformation proxies operators of this > situation. We're not prohibiting reissuing requests, we're just observing > that content providers don't like it. But you're doing it with normative language. If it's just an observation, make a little note or sidebar which explains the situation. I do object to the use of the word "theoretical" though. As I said, GET is safe and idempotent by definition, so I'd like to see that changed too. Mark.
Received on Friday, 20 November 2009 16:33:10 UTC