Fixed #605 custom content-type setting not effected sometimes #701
Conversation
|
@18o is attempting to deploy a commit to the sparckles Team on Vercel. A member of the Team first needs to authorize it. |
src/server.rs
Outdated
| @@ -262,8 +262,16 @@ impl Server { | |||
| /// Adds a new response header to our concurrent hashmap | |||
| /// this can be called after the server has started. | |||
| pub fn add_response_header(&self, key: &str, value: &str) { | |||
| self.global_response_headers | |||
| .insert(key.to_string(), value.to_string()); | |||
| match key.to_lowercase().as_str() { | |||
There was a problem hiding this comment.
Hey @18o 👋
Thank you for the PR 😄 TIL about the web headers fact. Thank you ✨
However, I have one question. Why not make everything lowercase?
There was a problem hiding this comment.
It's a good question, I was only thought about the content-type thing.
Do you mean all keys in the global_response_headers make them into lowercase?
There was a problem hiding this comment.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
An HTTP header consists of its case-insensitive name followed by a colon (:), then by its value. Whitespace before the value is ignored.
I read this at MDN docs today.
There was a problem hiding this comment.
@18o ,
Do you mean all keys in the global_response_headers make them into lowercase?
There was a problem hiding this comment.
Yeah, we can make the keys in global_response_headers all uppercase or lowercase, in order to avoid issues like this.
There was a problem hiding this comment.
@18o , sounds good. Let us make everything lower_case . I haven't seen someone mistype all upper case headers.
There was a problem hiding this comment.
ok, it's implemented in the latest commit
… from Python code
|
Hey @18o 👋 Thank you for the PR. However, there was a more fundamental flaw in the code. It has been fixed in v0.47.0 😄 |
Description
This PR fixes #605
global_response_headersinServeris a DashMap, which is case sensitive.The default key is
Content-Typecan be stay together withcontent-typeinglobal_response_headers, so when it's extended , bothContent-Typeandcontent-typeare written to http header without fixed sequence, but the browser is case insensitive, so it will take the last value inContent-Typeandcontent-type, that's why this bug happened.