Opened 10 years ago
Closed 9 years ago
#32024 closed defect (bug) (fixed)
XML Feed has wrong 'Content-Type'
Reported by: | pvdl | Owned by: | stevenkword |
---|---|---|---|
Milestone: | 4.4 | Priority: | high |
Severity: | normal | Version: | 3.5 |
Component: | Feeds | Keywords: | has-patch |
Focuses: | Cc: |
Description
The XML feed has Content-Type: text/html
It should be: text/xml
Test:
curl -Is www.example.com/feed/
Attachments (2)
Change History (17)
#3
@
10 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 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.
#5
@
10 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. 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
#6
@
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.
#7
@
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
@
9 years ago
32024.2.diff correctly specifies which feed type we are looking and issues the correct header.
#9
@
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.
#10
@
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 content type.
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.