nsSearchSuggestions.js improperly handles POST method suggestion URLs




10 years ago
2 days ago


(Reporter: Jeremy Maitin-Shepard, Unassigned)


Firefox Tracking Flags

(Not tracked)




10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040808
Build Identifier: hg cvs-trunk-mirror 2008-04-10

In the case of a POST method suggestion URL, nsSearchSuggestions.js obtains "submissions" from nsSearchService.js, and then passes its postData property to XMLHttpRequest send method.  However, nsSearchService.js creates a postData input stream that is suitable for e.g. nsIWebNavigation.loadURI but unsuitable for XMLHttpRequest, because it has MIME headers added to it, and XMLHttpRequest.send, as is explicitly documented in nsIXMLHttpRequest.idl, expects an input stream without headers added; instead, all headers are supposed to be added using addRequestHeader.

The result is that if a POST method is used, because no Content-Type header is specified to XMLHttpRequest, it defaults to application/xml, and then the body of the request gets mangled, in that it first contains some header lines and then has application/x-www-form-urlencoded data following that.

This bug probably has not been noticed before because none of the standard search providers use POST requests.

Note: I verified this problem by analyzing the traffic Firefox was generating using Ethereal.

Reproducible: Always
Ever confirmed: true

Comment 1

10 years ago
Note: One solution may be to not use XMLHttpRequest directly in nsSearchSuggestions.js, and instead use a lower level interface.  Another solution may be to use an additional layer of abstraction in what is returned from getSubmission (this is the approach I took in Conkeror): instead of returning a single channel, have getSubmission return something that internally stores just the post data as a string and the mime type, and then allow the user to either request those individually, or alternatively to request a stream, in which case a mime stream is created on demand.

Comment 2

2 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.