Every XHR GETs and others include bogus "Content-Type" header

[Randy Hudson]

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.

[cjolif]

See #12141. This was for pre-1.8 but maybe it applies here as well?

[Bryan Forbes]

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?

[matthesrieke]

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.

[dylan]

@matthesrieke, we'll of course consider a fix if you provide a PR!

[dylan]

@matthesrieke were you still interested in providing a PR for this?

[dylan]

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.