Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Case sensitivity of ETag header causes an issue for VCR #434
I've been using fog on a project and wanted to use VCR for stubbing the HTTP stuff. The latest Excon addresses a few issues and I've addressed a few more in the the current master branch of VCR, but there's one more issue I'm trying to sort out.
When VCR records an HTTP interaction, it normalizes the casing of the HTTP headers.
Overall, I would consider this a bug in VCR, but fixing it is anything but simple. VCR has the header normalization logic due to the nature of how it was developed: it was initially just a tool for recording Net::HTTP requests with FakeWeb, and it was only later expanded to support other HTTP stubbing libraries and other HTTP client libraries.
Long term, I have plans for some changes to the VCR cassette format that would include changing this behavior so that HTTP headers are preserved exactly-as-is--but that's down the road, probably for 2.0. In the short term, I'm OK putting in a slightly hacky work-around to treat the
I started working working on this today but have been stumped by the fact that Rack itself normalizes
All that is to say...I'm not sure what the right short-term fix is. Would you consider changing Fog's logic to be tolerant of different casing for HTTP headers (or at least for ETag)? i'd definitely consider this a bug in VCR, not in Fog, but given the fact that it's impossible to return an ETag header with some servers (like Rack) making it case-insensitivity would seem to make the Fog logic more robust anyway.
Long term, I hope to get VCR to the point where it never touches the casing of HTTP headers since there's simply no way to ensure the response is played back the same when it does so.
Any reason why you prefer this over the built in stuff with
Changing things for this one particular case probably wouldn't be too hard, but being case insensitive is a performance hit that I'm not the most keen on incurring for a case that (in so far as I'm aware) few people will encounter since most will use it live or with
I'll have to think about how else we might do something about this, and/or if I want to relax my performance concerns a bit for convenience. It is probably sensible that rack normalizes things, but unfortunate it does it that way. Anyway, leaving this on the back burner for the time being.
No worries--as I said, I consider this to be a bug in VCR, not a bug in Fog. I just wanted to open a dialog so I'm not trying to figure out the right solution on my own.
I'm going to think some more about a short term fix in VCR.
referenced this issue
Jun 27, 2014
@geemus yes, I'm on the latest for all of these gems. With
PS. Currently I'm using
It's hard to say for sure without seeing the example that is causing the error, but in general this happens when a