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

Handling of RFC7540 8.1.2.5 specification #189

Open
juliuskreutz opened this issue Apr 7, 2024 · 4 comments
Open

Handling of RFC7540 8.1.2.5 specification #189

juliuskreutz opened this issue Apr 7, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@juliuskreutz
Copy link

Hi Team,

I would like pingora to follow the RFC7540 8.1.2.5 specification or at least a feature that would allow switching between the old and new specification.

This has become a problem, because a website I'm working on can't handle the old way of parsing cookie headers

// old way
cookie: a=b
cookie: c=d
cookie: e=f
// new way
cookie: a=b; c=d; e=f

The issue lies in the h2 crate. I have mentioned this to the maintainers but they have decided that

The place to implement that is in systems that do provide such things, such as Pingora

Hence why I'm requesting this feature

@drcaramelsyrup drcaramelsyrup added the enhancement New feature or request label Apr 9, 2024
@eaufavor
Copy link
Member

Is my understanding correctly that you want a feature that transform the cookie headers in the old format to the new format when the system proxies the traffic to a HTTP/1.1 upstream?

@juliuskreutz
Copy link
Author

Hi!

I did forget to specify, that this only needs to be done for HTTP/2 upstream. This can be either a feature or standard

@eaufavor
Copy link
Member

eaufavor commented Apr 19, 2024

RFC7540 8.1.2.5 only requires this conversion to happen

before being passed into a non-HTTP/2 context

But I do see that this could be an useful feature.

On the other hand, many cloud APIs requires signed URLs, which means that any modification on the request headers could break these API traffic. So if we have such a feature it would be optional and default off.

@juliuskreutz
Copy link
Author

Yes I agree

such as an HTTP/1.1
connection, or a generic HTTP server application.

Does mean only concatenating the cookie headers, if the context changes. Maybe a feature or flag could be useful to indicate a change of context in a proxy.

And yes, the default should be off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants