Skip to content

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