XML Feed has wrong 'Content-Type'

[pvdl]

The XML feed has Content-Type: text/html
It should be: text/xml
Test:
curl -Is www.example.com/feed/

[pvdl]

And Content-Type for www.example.com/feed/atom/ should be:
application/atom+xml

BTW: I am not sure which Content-Type is correct for XML
application/rss+xml
or
text/xml

The strange part is: In the HTML source code the content-type of the feed is specified correctly, but it doesn't reflect in the output of the feed.

[mdgl]

See #16544.

[dd32]

This is caused by #14348, and as such only occurs on HEAD requests.

For example:

$ curl -I https://dd32.id.au/feed/ | grep 'Content-Type'
Content-Type: text/html; charset=UTF-8
$ curl -i https://dd32.id.au/feed/ | grep 'Content-Type'
Content-Type: text/xml; charset=UTF-8

with cURL, -I is a HEAD request, while -i is a GET request with headers shown.

I'm not sure what the expected behaviour should be here, obviously the feed headers should be shown, but we're exiting far earlier than the template is included.

[pvdl]

If you are using an online HTTP-Response checker, you get the correct Content-Type.
(Using GET request)
Check URL via e.g. ​http://web-sniffer.net/

I tried also a Non-WordPress website and checked their RSS feed.
Both with a GET (curl -is ...) and a HEAD (curl -Is ...) HTTP-request.
Output on both tests the content-type was: application/rss+xml

[stevenkword]

Looking around at other popular feed generators, it appears the expected behavior for HEAD request is to return Content-Type: text/xml; charset=UTF-8 for RSS and Content-Type: application/atom+xml; charset=UTF-8 for ATOM.

While it appears that the HTML request are correct, the HEAD requests are not. I'm looking into it.

[stevenkword]

Adds content-type field to request headers

[stevenkword]

Previously, the Content-Type was defaulting to text/html for all feeds as a fallback for when the field was not explicitly specified. 32024.diff​ adds a new field to the $headers array found in the send_headers method which will properly set the Content Type for all feed Request Headers in addition to the HTML headers manually set in each individual feed template.

[stevenkword]

32024.2.diff​ correctly specifies which feed type we are looking and issues the correct header.

[rmccue]

I approve of 32024.2.diff​, seems silly that we missed this before. I know of a few feed readers that probably break during autodiscovery because of this.

[stevenkword]

Specifies which feed

[stevenkword]

@rmccue -- mind taking another quick look? I just bumped 32024.2.diff​ to handle the case where the query_vars[ 'feed' ] is set to 'feed' instead of a specific feed format.

[wonderboymusic]

In 33658:

Ensure that feeds are served with the proper Content-Type HTTP header.

Props stevenkword.
Fixes #32024.