[qooxdoo-bugs] [Bug 5571] New: qx.io.request.Xhr: competing API - accept vs requestHeaders
Brought to you by:
ecker,
martinwittemann
From: <bug...@qo...> - 2011-08-31 09:27:45
|
http://bugzilla.qooxdoo.org/show_bug.cgi?id=5571 Summary: qx.io.request.Xhr: competing API - accept vs requestHeaders Product: framework Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: io AssignedTo: tri...@1u... ReportedBy: Tin...@1u... QAContact: tri...@1u... In the qx.io.request.Xhr class a convenient property "accept" is available. In addition to this a requestHeaders is available. These properties are in competition, as you can add "Accept" headers with both properties. This has the following effect: When using the JSON store, the "accept" header "application/json" is set by default. When the application sets another "accept" header "application/json" via the requestHeaders property ("because it can"), the accept headers get concatenated: Accept:application/json, application/json It seems like the call of this.__nativeXhr.setRequestHeader(key, value); in the BOM Xhr implementation, concatenates same named accept headers. In my opinion we shouldn't concatenate the set accept headers. If the user wants to use (which is valid) several types for the accept header, he should add them on its own. So the accept property should introduce an apply method, that adds the set value to the "requestHeaders". By doing this, we could easily override the default accept header, even by using the "requestHeaders" property. Another question is, do we need the convenient property "accept", when it just adds a requestHeader? This change might deprecate API. -- Configure bugmail: http://bugzilla.qooxdoo.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. |