Skip to content

Cache write is failing when converting ASCII-8BIT characters to UTF-8 #38

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

Closed
salbertson opened this issue Apr 17, 2014 · 7 comments
Closed

Comments

@salbertson
Copy link
Contributor

I'm getting a Encoding::UndefinedConversionError exception when trying to cache GitHub responses. Some responses will be cached, but some will fail to write because of an encoding conversion issue.

I'm using faraday 0.8.8 and faraday-http-cache 0.4.0 and here's the backtrace.

Any help would be greatly appreciated.

@salbertson salbertson changed the title Cache write is failing when converting UTF-8 characters to ASCII-8BIT Cache write is failing when converting ASCII-8BIT characters to UTF-8 Apr 17, 2014
@lucasmazza
Copy link
Collaborator

@salbertson there is any public URL that is producing this error that we can use to debug it?

@salbertson
Copy link
Contributor Author

@salbertson
Copy link
Contributor Author

I created a branch with a test to reproduce the issue. My first thought was to skip the write if the encoding fails.

salbertson/faraday-http-cache@master...sa-skip-write-when-encoding-errors

@lucasmazza
Copy link
Collaborator

@salbertson thanks for the report. I'm not sure of how to fix this without messing up with the response, as the issue lies with net/http not handling encoding properly and JSON failing hard when converting the body to UTF-8, but it sucks to ship with broken defaults like that.

On your app you can swap the serializer to Yajl or Marshal and they should handle the serialization better.

In the mean time, a PR that emits a warning with the storage logger (instead of puts) will be very appreciated 😄.

@salbertson
Copy link
Contributor Author

@lucasmazza using Marshal worked perfectly. Thanks, I'll get a pull request opened for the warning.

salbertson added a commit to houndci/hound that referenced this issue Apr 17, 2014
* Cache requests to limit requests that count against rate limit
* Use Marshal for serialization instead of JSON because of serialization issue

sourcelevel/faraday-http-cache#38
@monfresh
Copy link

I just ran into this as well, and I was able to get rid of the error by using Marshal as the serializer, but now I'm getting this error for some URLs:

incompatible marshal file format (can't be read)
    format version 4.8 required; 123.34 given

Any idea what might be causing this and how to fix it?

Thanks!

@skorth
Copy link

skorth commented Dec 17, 2014

Using Rails 4.2.0.rc3, warden-github, octokit and faraday-http-cache runs into a ASCII-8BIT to UTF-8 error. Its about the response body that holds a german "umlaut" like ü,ä or ö. As long as i use the faraday-http-cache middleware i get this error. Only way is to set Marshal as serializer instead of JSON. Didn't found any other solution for now.

elifoster added a commit to ghuls-apps/ghuls-lib that referenced this issue Nov 20, 2015
slumos pushed a commit to slumos/ruby-client that referenced this issue Feb 2, 2016
Below copied from launchdarkly#51 (comment)

Almost have this integrated, but wanted to mention that I ran into the
same problem mentioned at sourcelevel/faraday-http-cache#38. There's a
gem that supposedly works around the problem that ultimately lies with
Net::HTTP, https://github.com/ma2gedev/faraday-encoding, but for now I
just changed the serializer to Marshal as in
https://github.com/andrew/contribulator/pull/47/files.

I also added back our LDClient#add_user_override to my fork. Not sure if
you were planning to implement that, but if not then I'll move it
elsewhere so we can use your gem unmodified.
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

4 participants