Opened 6 years ago

Last modified 2 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 6 years ago by cjolif

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

comment:2 Changed 5 years ago by 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?

comment:3 Changed 3 years ago by 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.

Last edited 3 years ago by matthesrieke (previous) (diff)

comment:4 Changed 3 years ago by dylan

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

comment:5 Changed 3 years ago by dylan

Milestone: tbd1.11

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

comment:6 Changed 3 years ago by dylan

Milestone: 1.111.12

comment:7 Changed 2 years ago by dylan

Milestone: 1.131.15

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

Note: See TracTickets for help on using tickets.