#51324 closed defect (bug) (wontfix)
sitemap.xml and sitemap-xml headers return html as content type
| Reported by: | superpoincare | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Sitemaps | Version: | 5.5 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
If WordPress is installed at https://www.example.com, then the addresses https://www.example.com/sitemap.xml and https://www.example.com/sitemap-xml send "text/html; charset=UTF-8" as the Content-Type header.
Of course these urls get redirected to wp-sitemap.xml which sends the correct header "application/xml; charset=UTF-8". Just wondering if the page before redirection should also.
Change History (6)
#3
follow-up:
↓ 4
@
5 years ago
- Resolution → invalid
- Status new → closed
This ticket is for WordPress 5.5 so this may have changed but sitemap.xml is not part of the WordPress core sitemaps. Not in 5.9 anyway... It redirects to wp-sitemap.xml
I verified the Content-Type headers for the index on wp-sitemap.xml and all sitemaps but always get application/xml; charset=UTF-8.
This issue may be no longer valid or related to a (sitemap) plugin?
#4
in reply to: ↑ 3
@
5 years ago
- Resolution invalid → wontfix
Replying to RavanH:
This ticket is for WordPress 5.5 so this may have changed but
sitemap.xmlis not part of the WordPress core sitemaps. Not in 5.9 anyway... It redirects towp-sitemap.xml
Thanks for testing! It does issue a 302 redirect, but also sends a Content-Type: text/html; charset=UTF-8 header, which is exactly what the ticket is about. This still happens in current trunk.
I verified the Content-Type headers for the index on
wp-sitemap.xmland all sitemaps but always getapplication/xml; charset=UTF-8.
This is also mentioned in the ticket, the header is indeed correct on actual sitemaps.
Given the lack of traction in the last 18 months, it looks like this might be an acceptable edge case and is not going to be addressed at this time. Feel free to reopen if there is still interest in working on this further.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Hard to see this as an enhancement in Canonical component. I's a bug in the Sitemap component, not?