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

content-type comparison is failing #2

Open
dh-harald opened this issue Dec 6, 2017 · 2 comments
Open

content-type comparison is failing #2

dh-harald opened this issue Dec 6, 2017 · 2 comments

Comments

@dh-harald
Copy link

dh-harald commented Dec 6, 2017

Hi,

In my case https://github.com/luca-moser/iris-cache/blob/master/cache.go#L119 failed, because my Content-type contains my encoding: Content-Type: text/html; charset=UTF-8
Therefore I can't use your provided values for content type (cache.ContentTypeHTML/cache.ContentTypeJSON)

Could you fix it somehow? For example trim the variable after ;. It's not a big deal, but it could be better with a fix.

@luca-moser
Copy link
Owner

luca-moser commented Dec 6, 2017

The ContentType constants are merely the same values as used by iris (iris repo link).

With the Config struct, you are able to set a custom ContentType which should be cached (link).

So in your case supplying a Config to NewCacheHF or NewCache with a custom ContentType of "text/html; charset=UTF-8" should fix your issue.

I think it's faster when the user of the middleware supplies his/her used content types, since otherwise the middleware would have to do trimming and whatnot.

@dh-harald
Copy link
Author

I know, I'm already using that method, you suggested... (that was my workaround)
I've opened this ticket, because based on the documentation, the middleware couldn't working in special circumstances (eg. it's not caching anything).
Just because of nature of Content-Type header, you could easily trim it after ;, and the content type values could work afterwards...

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

No branches or pull requests

2 participants