cdent
JSON assertions fail without Content-Type response header
If the server responds with a JSON payload without also providing the appropriate content type, response_json_paths assertions result in a cryptic error:
left hand side json path […] cannot match None
I believe this this was a design decision early on (IIRC), expecting well-behaved servers - thus defying Postel. In my case, I have no control over the server in question, so there's no reasonable way for me to use Gabbi here.
It's okay for us to track this as a missing feature/bug/whatever.
I think the reason for not allowing broken web servers in the past was not because we wanted to defy Postel, but because early on at least, it was servers (that is apps running their own servers) that were being tested and doing HTTP wrong was not something we wanted to allow.
Now if we want to make this possible, there's no non-invasive way to make this work. We'd need to add something like a fallback_content_type attribute as a test field so that the response handler gets triggered even when the response doesn't identify itself.
I had considered suggesting such a non-invasive option, but hesitated because it feels like a crutch that could require similar crutches for almost anything.
Having said that, how about making it flexible:
response_header_overrides:
Content-Type: application/json
That way Gabbi doesn't need to have opinions on any particular fallback/override.
I'm going to use those icky stupid words: That feels a bit like a slippery slope.
The slippery slope is probably the right solution because it satisfies the problem in a general way, but on the other hand it make needing fallbacks or overrides "normal" and I kinda hate that.
If we decided to move forward with something like this we would need to do decide if the value was a fallback for when the header was not present, or an override for all instances.
The latter would be even further down the slippery slope of yucky.
As discussed elsewhere, I sympathize with your concern, but regard it as less severe - in part because overrides can be temporary and indeed offer a path to improve the respective server implementation. IOW: more rope than slope.
My gut feeling is that if the client wants to define response headers, they actually want override rather than fallback: It's more deterministic and would also help in situations where the server sends incorrect values.
that if the client wants to define response headers, they actually want override rather than fallback
This is likely true.
Will take a little investigation to figure out how much change it will require. Probably not all that much.