Expose more granular header control about http-streams HOT 9 CLOSED

Hey there.

Low hanging fruit first:

• Make setHeader "Host" override the default Host header.

That's already available and there are tests which check it. Call setHostname with whatever you need.

• Get rid of the default User-Agent header.

Hmmm. Disinclined; an appropriate User-Agent string is part of being a good net citizen. I'm a bit vague why your signatures are being made on some precalculated headers set and not the live headers being processed in a given connection; last I checked the latter is what you had to do with e.g. S3.

• Add getHeaders to the RequestBuilder monad.
• Expose deleteHeader.

So not all the headers that go out are determined by what's in the Headers map being built up; it's the Request object['s internals] that are being populated and as you've seen, some fields are special. It was a pretty deliberate design decision not to expose those internals; they drive behaviour at other layers when the request gets composed.

I want you to be able to use http-streams, obviously, but we've gone to some trouble to make the common usage work well such that you can't shoot yourself in the foot. Maybe if you post your code somewhere that we can have a look we can get a better idea of the use case you're struggling with.

AfC

from http-streams.

Ok, that makes sense.

I guess we could rig it that if a header is present manually set that it overrides the default, assuming at least some sanity checking. Probably just allow people to shoot themselves in the foot but your request is not unreasonable.

Things like Content-Length still do pass through the headers Map, but they also set additional metadata in the Request object. We'd have to build a check into setHeader whenever it was called which would iterate over all the special cases to look out for the magic ones and Do The Right Thing if it was.

That slows down setHeader but whatever. A reasonable thing to offer.

A hypothetical deleteHeader might be harder. Tha's a 2P CRDT thing :). Would being able to getHeader "User-Agent" be sufficient for your requirements?

AfC

from http-streams.

Sorry, had some intermittent connection issues while editing a previous comment .. now it's not here.

I guess (related to #38) another alternative regarding the getHeaders proposal would be to provide it on the resulting Request (rather than exposing the ctor that #38 mentions).

deleteHeader was not really a serious suggestion and I think providing a way to get the immutable header map after it has been set, before sendRequest or such is a better way forward. The function getHostname :: Connection -> Request -> ByteString provides a similar API.

Would that avoid the need to modify setHeader?

This scenario really only cares about getting the final resulting headers (which can be supplemented by getHostname) before send, not actually inside the RequestBuilder monad.

from http-streams.

Actually, now that I think about it, you can already cause damage with setHeader. But that's a separate matter. There's no reason not to offer you a getHeaders, though I'll want to give the exact shape some thought as there are also response headers to think about and I'd like to avoid a typeclass.

AfC

from http-streams.

@brendanhay So what do you actually need? The request (headers) as a whole?

getRequestHeaders :: Connection -> Request -> ByteString

easily done. Or a full pair list?

getRequestHeaders :: Connection -> Request -> [(ByteString, ByteString)]

which involves undoing what has been done to build it in the first place, but whatever. Or do you really need me to go the whole hog and expose Foldable instances etc.

AfC

from http-streams.

The first signature isn't particularly useful, I can get it now by parsing the Show instance output. 😄

The latter signature is considerably more so, rather than having to implement header decoding - although that's not a big deal.

Since the whole join/split process should be bijective anyway (not sure if you're using a dependency or hand-rolled) it could be used for tests as well.

It would also avoid the need for Foldable etc since it's just an assoc list, imo.

Cheers!

from http-streams.

Thanks a lot, mate!

from http-streams.

@brendanhay fyi, I'm working on something right now for which the best solution may well be to no longer have http-streams set the User-Agent header. You'd actually prefer that, right?

AfC

from http-streams.

Right, in combination with getHostname it would be sufficient as long as the other default header (Accept-Encoding I think?) was known.

from http-streams.