Opened 7 years ago
Last modified 3 years ago
#16566 new defect
Every XHR GETs and others include bogus "Content-Type" header
Reported by: | Randy Hudson | Owned by: | Bryan Forbes |
---|---|---|---|
Priority: | undecided | Milestone: | 1.15 |
Component: | IO | Version: | 1.8.3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
If you make an XHR GET (and I think other methods like HEAD), the Request that is sent to the server contains a bogus header:
Content-Type: application/x-www-form-urlencoded
This header bogus for an HTTP Request that never contains an entity. At best it is wasted bandwidth, but at worst it could break caching by browsers or intermediate proxies. It can also be flagged as an error by HTTP traffic analysis tools.
Change History (7)
comment:1 Changed 7 years ago by
comment:2 Changed 6 years ago by
This is a hold-over from pre-1.8 (and still applies for 1.8+). The reason the default is application/x-www-form-urlencoded
is because if you pass an object to dojo/request
as the data
parameter, it encodes it like a form would (so the content type is right in that case; dojo.xhr
does the same thing for content
and postData
). There could possibly be a check to see if we're URL encoding the payload and, if so, set the content type, but is it critical? What browsers will prevent caching because of that header?
comment:3 Changed 4 years ago by
I am seconding this issue. Recently I got a server that I need to connect, that refuses to answer when the Content-Type header is set. Here is a CURL example. This is really annoying, and there is absolutely no need for this header in a plain GET request with no payload.
curl -H "Content-Type: application/x-www-form-urlencoded" "http://geodienste-hamburg.de/HH_WMS_Geotourismus?REQUEST=GetCapabilities&SERVICE=WMS"
I could create Pull Request on GitHub?, if there is an interest in fixing this.
comment:5 Changed 4 years ago by
Milestone: | tbd → 1.11 |
---|
@matthesrieke were you still interested in providing a PR for this?
comment:6 Changed 4 years ago by
Milestone: | 1.11 → 1.12 |
---|
comment:7 Changed 3 years ago by
Milestone: | 1.13 → 1.15 |
---|
Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.
See #12141. This was for pre-1.8 but maybe it applies here as well?