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

fix: ignoring response header field space #1921

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

prepaser
Copy link
Contributor

Closes #1917
Ignore when the header key contains spaces.

for _, ch := range s.key {
if !validHeaderFieldByte(ch) {
if ch == ' ' {
spaceIncluded = true
break
Copy link
Contributor

Choose a reason for hiding this comment

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

If there are invalid characters after space, the validHeaderField will be skipped. I think break should be changed to continue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, you're right. I didn't think that...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed! Thank you!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wait a minute... Come to think of it, I'm going to ignore it anyway, but do we still need validation? If we need validation of the header key, don't we need validation of the header value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think there are two choices, one is to validate both the key and the value because if there is the wrong byte, it should fail, and the other is not to do it after have checked the space. And wouldn't it be right not to validate it for fasthttp? I think it would be better to skip the minor verification.

Copy link
Contributor

Choose a reason for hiding this comment

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

In net/http, they handle headers even if they contain spaces. I just realized that you directly ignore this header field. Although I think we should follow the behavior with net/http instead of skipping this header.

We can ask @erikdubbelboer for his opinion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wanted to follow that action if possible, but net/http doesn't canonicalize the header afterwards, but fasthttp normalizes it through disableNormalizing, so I decided to just ignore it. This is also because it is a common behavior for Internet browsers. If you have any ideas, please let me know.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I also prefer it if we follow the behavior of net/http as that is really well tested.

@prepaser prepaser force-pushed the ignore-header-field-spaces branch from 419d178 to 1c9a91e Compare December 13, 2024 11:56
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.

Ignoring parsing errors of parseHeaders in client.go
3 participants