Re: [Chicken-users] http-client: distinguishing between responses 301 and 302

[Jörg F . Wittenberger]

On Oct 18 2018, John Cowan wrote:

> 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.

John, to me this does not look as if Norman was using the http-client for a 
general purpose client. But more like a dev/testing tool.

Anyway. I'm looking into http-client with similar worries. Ages ago I wrote 
some http client+server code (using rscheme at that time) which is since 
used in a rather unusual setting: It is used to replicate incoming requests 
to a network of machines each hosting many state machines (a.k.a. 
communication sequential processes, a.k.a. agents) in byzantine fault 
tolerant replication. (Things are always implemented in LISP first. Smart 
contracts too. ;-)

Now I want to replace that mess I wrote over 15 years ago with an 
alternative implementation I don't have to maintain alone. http-client 
comes to mind.

Looking closer I don't like to install exception handlers in order to 
handle the http status. That might be a matter of taste.

Then, when replicating a request, the same payload is send to several 
receivers. I'd like to not repeat the serialization process. However in 
order to account for different bandwidth to certain peers, there is the 
need to half way synchronize the delivery of the last byte(s) of each 
stream until at least the majority of the peers has received all of the 
request.

Things I'd like to do with http-client.  But it looks complicated.

So maybe the high level interface of http-client is simply not the one 
Norman wants to use.

Best

/Jörg

> On Thu, Oct 18, 2018 at 1:20 PM Norman Gray <address@hidden> wrote:
>
> > Greetings.
> >
> > 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
> > redirect-depth-exceeded)>
> > list=(
> > (exn (arguments ("http://localhost:8081/host/";))
> >    (message "Maximum number of redirects exceeded")
> >    (location send-request))
> > (http)
> > (redirect-depth-exceeded
> >    (request #<request>)
> >    (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.
> >
> > Best wishes,
> >
> > Norman
> >
> >
> > --
> > Norman Gray  :  https://nxg.me.uk
> >
> > _______________________________________________
> > Chicken-users mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/chicken-users