search

parroty / exvcr

HTTP request/response recording library for elixir, inspired by VCR.
MIT License
727 stars 133 forks source link

JSON serialization => type losses #12

Open nicoolas25 opened 10 years ago

nicoolas25 commented 10 years ago

I had issues using ExVCR because of transformations that have been made on the request / responses to save them. The JSON deserialization made all the strings as Elixir's String (no character list anymore) and my oauth lib (tim/erlang-oauth), expected a character list :-( Do you see where my problem is?

Why not using an Erlang representation instead of JSON? You'll avoid many conversions... I tried this idea here if you're interested: https://github.com/nicoolas25/exvcr

Thank you for this work. With my minor adjustments it is very usefull!

parroty commented 10 years ago

Thank you for taking time on this. I'm having difficulty to take time for a while, but will be looking into this one.

edgurgel commented 10 years ago

It's not a bad idea to have an option to store JSON or erlang terms (binary file in this case?).

nicoolas25 commented 10 years ago

I stored it with :io.format('~w.', term) and parsed it back with the :erl_{parser,scanner,..}. It may exist a better technique out there...

parroty commented 10 years ago

Having serializer option sounds reasonable, but I'm wondering that whether it can be resolved by adding option (retain original char-list type) or additional meta information in the json file (store type information). Also, it seems the Ruby's VCR is taking custom serializer approach in addition to native YAML/JSON support. Please let me play around a little more.

nicoolas25 commented 10 years ago

With the JSON serializer I also noticed that when there is the same HTTP header multiple times like set-cookie there is some loss too. Only one header is kept.

niklas commented 8 years ago

I stumbled upon this issue when vcr-ing the fetch of an image (JPEG) using HTTPoison. In the first run, everything works as expected, but on the second run (with data deserialized from JSON), the body: data I get back is roughly twice the size and (after File.write!) not a valid JPEG anymore.