- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 23 Feb 2010 12:36:01 +0100
- To: "Hans Meiser" <brille1@hotmail.com>, public-webapps@w3.org
On Tue, 23 Feb 2010 12:29:59 +0100, Hans Meiser <brille1@hotmail.com> wrote: >>> I believe this spec ought to be updated to also exclude POST data from >>> being uploaded for HTTP request methods like DELETE, TRACE, OPTIONS. >> >> As I said in the bug, we do not want to constrain HTTP more than we >> already do. > > I believe this is not a question of wanting but a question of definition > and browser compatibility. Indeed. And as such we are doing the right thing here. >>> Plus, I believe upload should be allowed to be send along with HEAD >>> requests, because if the page would usually respond to POST requests, >>> it can only return useful results like Content-length if the HEAD >>> request >>> would upload the same data as POST. >> >> I do not understand what you mean here. GET/HEAD are semantically >> equivalent, not HEAD/POST. > > Yes, sure. But a HEAD request is usually being used to obtain a web > server's headers on a specific resource. If that resource is configured > to respond to POST requests only (e.g. a PHP page responding to uploaded > form data), the headers returned by this resource ought to be the same > headers a HEAD request would obtain. No: http://tools.ietf.org/html/rfc2616#section-9.4 > So if a web server's resource would respond to a HTTP POST request with > headers containing, e.g., Content-length information (or any header > computed from the uploaded POST data) then a HEAD request should yield > the same headers. Otherwise the HEAD information retrieved would be > useless in order to take decisions on whether to load the full resource > using a POST request. > > Do you see my point? I think so, but I believe you are wrong. -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 23 February 2010 11:36:37 UTC