Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(models): use preferred notation for JSON content-type #204

Merged
merged 1 commit into from
Jan 22, 2025

Conversation

Zerotask
Copy link

@Zerotask Zerotask commented Jan 22, 2025

I noticed that the content-type looked like this:
"Content-Type": "application/json; charset=\"utf-8\"",

and then I checked the corresponding RFC (7231) to see if that's valid.
It is valid, but not the preferred way.

image


Update: reference to RFC9110

@Ousret Ousret self-requested a review January 22, 2025 11:26
Copy link
Member

@Ousret Ousret left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. rfc9110 (supersede rfc7231) still say the same.

@Ousret Ousret merged commit d06129d into jawah:main Jan 22, 2025
34 checks passed
@Zerotask Zerotask deleted the patch-1 branch January 22, 2025 11:49
@Ousret Ousret mentioned this pull request Jan 22, 2025
Ousret added a commit that referenced this pull request Jan 22, 2025
3.12.2 (2025-01-22)
-------------------

**Fixed**
- Parsing of special scheme that exceed 9 characters on rare custom
adapters.

**Changed**
- Default `Content-Type` for json payloads changed from
`application/json; charset="utf-8"` to `application/json;charset=utf-8`.
While the previous default was valid, this is the preferred value
according to RFC9110. (#204)

**Misc**
- Removed a useless hasattr control to support older version of
urllib3-future (<2.5).
- Updated our pre-commit configuration and reformatted files
accordingly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants