[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] http-client: distinguishing between responses 301 an
Re: [Chicken-users] http-client: distinguishing between responses 301 and 302
Thu, 18 Oct 2018 15:49:49 -0400
The difference between 301 and 302 is primarily relevant to crawlers and caches. I agree that it needs to exist, but not clear that a general-purpose client needs to expose it. Can you explain your use case more clearly? Thanks.
In http-client, is there any way of distinguishing between server
responses 301 and 302?
In test code, I want to confirm that a server is responding with the
correct redirection code, but can't quite get there.
If I make a request using call-with-input-request and the server
produces a redirection, then the client code follows the redirection.
If I parameterise that with (parameterize ((max-redirect-depth 0)) ...),
then the client library doesn't follow the redirection but instead
raises (exn http redirect-depth-exceeded). That's almost there, except
that the exception doesn't contain information about _which_
redirection, 301 or 302, prompted it. Using (condition->list), I get
redirect-depth-exceeded: e=#<condition: (exn http
(exn (arguments ("http://localhost:8081/host/"))
(message "Maximum number of redirects exceeded")
(new-uri #<URI-common: scheme=http port=8081 host="localhost" path=(/
"top" "host") query=() fragment=#f>)
(uri #<URI-common: scheme=http port=8081 host="localhost" path=(/
"host" "") query=() fragment=#f>)))
The documentation for call-with-input-request* doesn't suggest that it
behaves differently from call-with-input-request in this respect. And
although call-with-response mentions the possibility of redirects, and
multiple calls to 'reader', it doesn't suggest that the reader procedure
has any access to the response headers.
Is there any other way of getting this status code, or do I feel an
enhancement request coming on?
Possibly better than this handling of redirect-depth-exceeded would be a
parameter follow-redirects? which defaults to #t, or having
call-with-input-request return normally (ie, without the exception) in
the particular case that max-redirect-depth is 0.
I'm using Chicken 4, but as far as I can see, the Chicken 5 http-client
is identical in this behaviour.
Norman Gray : https://nxg.me.uk
Chicken-users mailing list