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

Remove text/html; fragment from accept header #37

Merged
merged 2 commits into from
Mar 10, 2020

Conversation

koddsson
Copy link
Contributor

This is a breaking change and would need a major version bump.

Varnish will choke on ; in a accept header so we need to remove it and only rely on the text/fragment+html header.

@koddsson koddsson requested a review from a team March 10, 2020 08:57
Copy link

@dbussink dbussink 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 quickly jumping on this.

@keithamus
Copy link
Member

To clarify; Varnish does not choke on this - nginx does. See #36 (review):

👍

I'd like to put it here for posterity:

The Accept header, as defined in RFC2616 Sec 14.1 does allow for text/html; fragment. An Accept header consists of a media-range (which is a media-type where the mime can be or type/* or */*) followed by any number of accept-params (which are ; token or ; token = "string" ). The Content-Type header (defined by RFC2616 Sec 14.17) allows for a media-type (defined in Sec 3.7) which looks much the same but cannot use the media-range wildcards.

text/html; fragment is a perfectly valid media-type, therefore a perfectly valid Content-Type header and also a valid Accept header.

The reason this needs to be done is that for certain parts of Nginx - namely the gzip module, and how it determines it can gzip content - only accepts mime-types not media-types. Mime Types are different to Media Types and only allow for a grammar of type/subtype or type/extension+subtype (as defined in RFC2045).

In other words, when nginx sees a Content-Type header of text/html; fragment - it discards it as an invalid Mime Type and will not gzip it. Nginx is both wrong and right here - text/html; fragment is not a valid mime type! But Content-Type is not a header that contains only mime types! So nginx is not following the spec.

Getting nginx to follow the spec and have gzip allow lists use Media Types over Mime Types is an uphill battle compared to simply changing our Media Type to be one that is acceptable as a Mime Type, hence this change.

@koddsson
Copy link
Contributor Author

To clarify; Varnish does not choke on this - nginx does. See #36 (review):

Ah yes, my mistake. I keep conflating the two.

@koddsson koddsson merged commit 5574169 into master Mar 10, 2020
@koddsson koddsson deleted the remove-fragment-header branch March 10, 2020 12:17
@keithamus
Copy link
Member

After speaking with @dbussink, normalisation is present in our VCL so this is actually Varnish causing this issue. That being said the nginx issue may still be prevalent here.

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.

3 participants