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

reverseproxy: ignore RFC 1521 parameters in mime type when checking the Content-Type header #3758

Merged
merged 1 commit into from
Oct 1, 2020

Conversation

cmfcmf
Copy link
Contributor

@cmfcmf cmfcmf commented Sep 27, 2020

Without this change, a Content-Type header like "text/event-stream;charset=utf-8"
would not trigger the immediate flushing.

Fixes #3765

Without this change, a Content-Type header like "text/event-stream;charset=utf-8"
would not trigger the immediate flushing.
@CLAassistant
Copy link

CLAassistant commented Sep 27, 2020

CLA assistant check)
All committers have signed the CLA.

@cmfcmf cmfcmf changed the title Ignore RFC 1521 parameters in mime type when checking the Content-Type header reverseproxy: ignore RFC 1521 parameters in mime type when checking the Content-Type header Sep 27, 2020
@francislavoie francislavoie added the bug 🐞 Something isn't working label Sep 30, 2020
@francislavoie francislavoie added this to the v2.2.1 milestone Sep 30, 2020
@mholt
Copy link
Member

mholt commented Oct 1, 2020

Thanks for the PR! I will look at this soon.

... and I'm kinda beginning to wonder if -1 should be the default for everything at this point. Thoughts, @francislavoie / @mohammed90 ?

@francislavoie
Copy link
Member

Idk, that sounds like too risky a change to me 🤔

@mholt
Copy link
Member

mholt commented Oct 1, 2020

Why?

@francislavoie
Copy link
Member

Isn't there risk that we break behaviour for some clients? There must've been a good reason for it not to be set to -1 by default in stdlib, no?

The code comes from here https://golang.org/src/net/http/httputil/reverseproxy.go?h=FlushInterval#L410

Should we bubble this change upstream to see what they have to say? I know our proxy implementation is not dependent on it but it feels like we should let them know of fixes like this?

@mholt
Copy link
Member

mholt commented Oct 1, 2020

Isn't there risk that we break behaviour for some clients? There must've been a good reason for it not to be set to -1 by default in stdlib, no?

We don't know if it is likely to break anyone; the worst I imagine could happen would be a performance degradation. (I mean, I'm sure it could break someone but I doubt it'd be the majority case.)

Anyway, that's tangential, just thought I'd bring it up...

Should we bubble this change upstream to see what they have to say? I know our proxy implementation is not dependent on it but it feels like we should let them know of fixes like this?

Sure. Sounds like a good idea.

Copy link
Member

@mholt mholt left a comment

Choose a reason for hiding this comment

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

Thanks for the fix @cmfcmf !

@mholt mholt merged commit fdfdc03 into caddyserver:master Oct 1, 2020
@cmfcmf cmfcmf deleted the streaming-fix branch October 1, 2020 18:58
@cmfcmf
Copy link
Contributor Author

cmfcmf commented Jul 23, 2021

Should we bubble this change upstream to see what they have to say? I know our proxy implementation is not dependent on it but it feels like we should let them know of fixes like this?

Sure. Sounds like a good idea.

I have now opened an upstream issue about this fix: golang/go#47359

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐞 Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Server Sent Events are not working in a nodejs/express app
4 participants