Allow custom headers in responses
bernhard-hofmann opened this issue · 7 comments
On the website it shows that the service will return a response that includes
{any custom response headers}
It's not clear how a caller could provide custom response headers, or whether they're custom to the service. It would be useful for a caller to provide headers that they wish to have included in the response.
In terms of implementation, I cannot see the query string as a suitable source of key-value-pairs so I would suggest echoing HTTP headers that conform to a specified format, possibly as follows:
Client -> Server:
X-ECHO-ME-X-My-Special-Header: HeaderValue
Server -> Client: (Simply removes the X-ECHO-ME- prefix)
X-My-Special-Header: HeaderValue
TBH I didn't even know that the website said that (I don't tend to read the website much 🤣) so I had to go digging in the code to try and remember.
I think that it's not actually meant to work in the way you're thinking (and is implied), instead it's meant to mean custom headers required by the HTTP status, so things like the Location header for a 301 (I went and found when it first appeared in the docs and it was when we did https://github.com/aaronpowell/httpstatus/blob/703a82d211f04b320ac37b1cc42b74725f0d963b/site.rb, yes, it was originally a Ruby codebase!).
I'm curious as to what sorts of scenarios you're testing where you need to unpack the headers of the status code, not just rely on the status code itself
Thanks for taking the time to respond Aaron.
In order to use this for some custom implementations, I can imagine people might want the server response to include an x-api-key or similar to have the response from this service accepted/recognised as valid by the client code.
Would the client be wanting to validate that an API key came back in the header? I'd expect that that's more of a server consideration (you sent me an API key, I validated it and gave a response code based on that), and that's not something that I'll be able to get into the service, it really wouldn't fit the model.
I'm not adverse to using something like an X-HTTPSTATUS-ECHO header prefix to indicate something to echo, but it'll be a bit of code required so I want to ensure that it's solving something you're trying to do.
In my case, I want to test a 429 throttling response and have the response return a specific Rate-Limit-Reset header (rather than the standard Retry-After header)
That's a good use-case. Would sending a header in the request work for you @JustinGrote?
That's a good use-case. Would sending a header in the request work for you @JustinGrote?
Yes, basically if I send any headers, I want them mirrored back to me in the response. That would be simple and ideal.
It's about time, but it's done! It you prefix a header with X-HttpStatus- it'll return the header and value to you (minus the prefix)