[#43689] - Fix `content-type` header to `application/json`
- Closed
- 15 Nov 2024
- Medium
- Build: 4.4-dev
- # 43689
- Diff
- rubenferreira97:4.4-dev
- Pending continuous-integration/drone/pr Build is pending Details
User tests: Successful: Unsuccessful:
Pull Request for Issue #43641.
Summary of Changes
JsonDocument in Joomla 4.4.5 wrongly sets text/plain to all browsers (tested on Edge, Firefox and Chrome). Browsers do not usually send application/json, instead they send */* with some lower priority.
Note: Joomla 5 already fixed this, so this change needs to be merged to Joomla 4 (maybe Joomla 4.4.6?).
Testing Instructions
Ping and API endpoint that extends JsonDocument. In my case I am returning a normal json response instead of a json:api.
Actual result BEFORE applying this Pull Request
Ping an API endpoint like localhost/api/index.php/v1/example:
Content-Type: text/plain; charset=utf-8
Expected result AFTER applying this Pull Request
Ping an API endpoint like localhost/api/index.php/v1/example:
Content-Type: application/json; charset=utf-8
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
| Title |
|
||||||
@laoneo The PR which fixed this issue was #39397. IMO this is a bug that should be fixed since JsonDocument should always return application/json by default. Even the IE9 fix was a hacky workaround. Don't know about Joomla BC policy, but are people really expecting this and working around this behavior?
Problem is that this behavior did exist now for a long time. Changing it in a patch release might cause unexpected issues in extensions using that class as it belongs to the public API. We will discuss it in maintainers group and report back.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-11-15 13:47:33 |
| Closed_By | ⇒ | HLeithner | |
| Labels |
Added:
PR-4.4-dev
|
||
Closing this PR, since 4.4 is in security mode only and it's fixed in 5.x
Can you reference the pr which fixed this issue already in 5. The change here is a BC break, so not sure if the need to fix it weight's higher than the BC policy.