Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#32024 closed defect (bug) (fixed)

XML Feed has wrong 'Content-Type'

Reported by: pvdl's profile pvdl Owned by: stevenkword's profile stevenkword
Milestone: 4.4 Priority: high
Severity: normal Version: 3.5
Component: Feeds Keywords: has-patch
Focuses: Cc:


The XML feed has Content-Type: text/html
It should be: text/xml
curl -Is

Attachments (2)

32024.diff (681 bytes) - added by stevenkword 9 years ago.
Adds content-type field to request headers
32024.2.diff (861 bytes) - added by stevenkword 9 years ago.
Specifies which feed

Download all attachments as: .zip

Change History (17)

#1 @pvdl
9 years ago

And Content-Type for should be:

BTW: I am not sure which Content-Type is correct for XML

Version 0, edited 9 years ago by pvdl (next)

#3 @dd32
9 years ago

  • Type changed from enhancement to defect (bug)

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

For example:

$ curl -I | grep 'Content-Type'
Content-Type: text/html; charset=UTF-8
$ curl -i | 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.

#4 @dd32
9 years ago

  • Version changed from 4.1.1 to 3.5

#5 @pvdl
9 years ago

If you are using an online HTTP-Response checker, you get the correct Content-Type.
(Using GET request)
Check URL via e.g.

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

Last edited 9 years ago by pvdl (previous) (diff)

#6 @stevenkword
9 years ago

Looking around at other popular feed generators, it appears the expected behavior for HEAD request is to return Content-Type: application/rss+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.

Last edited 9 years ago by stevenkword (previous) (diff)

9 years ago

Adds content-type field to request headers

#7 @stevenkword
9 years ago

  • Keywords has-patch added
  • Owner set to stevenkword
  • Status changed from new to assigned

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.

#8 @stevenkword
9 years ago

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

#9 @rmccue
9 years ago

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.

9 years ago

Specifies which feed

#10 @stevenkword
9 years ago

@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.

Last edited 9 years ago by stevenkword (previous) (diff)

#11 @stevenkword
9 years ago

  • Priority changed from normal to high

#12 @stevenkword
9 years ago

  • Milestone changed from Awaiting Review to Future Release

This ticket was mentioned in Slack in #core by stevenkword. View the logs.

9 years ago

#14 @stevenkword
9 years ago

  • Milestone changed from Future Release to 4.4

#15 @wonderboymusic
9 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 33658:

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

Props stevenkword.
Fixes #32024.

Note: See TracTickets for help on using tickets.