Question about not having a method for getting all response headers

[elakito]

Hi,
The runtime ClientResponse API has a method for reading known headers but no method for reading/listing unknown headers.
https://github.com/go-openapi/runtime/blob/master/client_response.go#L24-L29

If one is using the runtime library with a specific swagger file and as the application level headers are all known a priori, those headers can be read using GetHeader(name). But if one uses the runtime library to dynamically invoke a service, the unknown response headers cannot be read at the moment.

Therefore, I am wondering if not providing a method for reading all the response headers in ClientResponse API is intentional based on the swagger usage or there may be a room for a change.

I am not asking for a change but I just would like to know about the decision taken and whether there have been a similar usage request from someone else.

Thanks.

regards, aki

[casualjim]

At the time I assumed that all the headers would be in the swagger specification, but that's just for the generated code. I may not fully understand your question because from what I see the response reader is responsible for parsing the headers out.

As far as I can tell we don't do anything special with the http headers, the response struct just wraps the http.Response object:

https://github.com/go-openapi/runtime/blob/master/client/response.go#L38-L40

The response reader is one you'd provide yourself if you're using the untyped API: https://github.com/go-openapi/runtime/blob/master/client_response.go#L41-L43

[elakito]

@casualjim What I mean is that the client.response wraps http.Response and exposes its GetHeader(string). So if you know the header name, you can read its value. But there is no method exposed to read all header entries, one cannot read unknown headers from the response.

[casualjim]

if you expect a particular header to exist, shouldn't it really be a part of the swagger definition? Especially for client operations?

[elakito]

I was wondering if the server returns some additional headers that are not defined in the application level swagger definition, if there is a way to read those headers as part of some middleware handling to react to those headers. But since this middleware handling code that are supposed to react to some specific headers must have known those headers, it could lookup these headers using their names.

Unless this middleware processing looks for headers generically like get all headers that start with some prefix, there is no need to have the API to return all headers. That was why I asked about the background behind this API and also wondered if someone had such need or not. My question has been answered and we can close this ticket.

regards, aki

[casualjim]

Yeah I guess there might be a case for it, but it still implies implicit knowledge of your system right?
There might be a case for it when you aren't in control of the API you're calling though.

[elakito]

I am closing this ticket as my question has been answered.
Thanks.