User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6
In the course of another bug (Bug 546930) found that in file nxXMLHttpRequest2.cpp uploading POST data is not performed if the HTTP protocol is GET because it's unnecessary there.
I believe the conditional logic is wrong. Uploading data is not only redundant on GET request, but also on HEAD, DELETE, TRACE, OPTIONS etc.
So I suggest to change the logic from
if (aBody && httpChannel && !method.EqualsLiteral("GET"))
if (aBody && httpChannel && (method.EqualsLiteral("POST") || method.EqualsLiteral("PUT")))
Steps to Reproduce:
Uploading is performed on any HTTP protocol except GET.
Uploading should only be performed on appropriate protocols.
The current specification for XMLHttpRequest at http://www.w3.org/TR/XMLHttpRequest/#the-send-method says:
If the request method is GET or HEAD act as if data is null.
If the data argument has been omitted or is null, do not include a request
entity body and go to the next step.
So you may want to raise this issue on <email@example.com>. At the moment, our behavior is more or less following the proposed spec (need to add HEAD to the blacklist).
I should note that the suggested change in comment 0 is definitely not acceptable, since it would make it impossible to send a body with extension methods. But perhaps some more existing non-extension methods need to be added to the blacklist.
We do not want to arbitrarily constrain usage of HTTP further I think. Doing it for GET was needed for compatibility and it was argued that HEAD should always be treated the same.
Thanks for your valuable replies! Actually I would even see a reason for uploading wenn issuing a HEAD: 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 made above blacklist solution just to make my point. It's not based on any further research, so please don't take it literally.
But, Boris, you are right, the issue should be brought up to the W3C. I'll add my question to the mailing list there.