W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

RE: XMLHttpRequest send() Method Uploads On Inappropriate HTTP Protocols

From: Hans Meiser <brille1@hotmail.com>
Date: Tue, 23 Feb 2010 12:29:59 +0100
Message-ID: <SNT130-w476B85AA66939353FAAFF8E2420@phx.gbl>
To: <annevk@opera.com>, <public-webapps@w3.org>

Hi Anne,

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



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

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?



Best regards,
Axel Dahmen
www.axeldahmen.de
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
Received on Tuesday, 23 February 2010 11:30:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT