[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] http-client: distinguishing between responses 301 an
From: |
Norman Gray |
Subject: |
Re: [Chicken-users] http-client: distinguishing between responses 301 and 302 |
Date: |
Fri, 19 Oct 2018 12:12:17 +0100 |
John, hello.
On 18 Oct 2018, at 20:49, 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?
It seems to me that the difference is relevant to users other than
crawlers and caches. As you know, 301 is saying 'this is the wrong URI;
don't come here again', but 302 is saying 'this is the right URI; see
over there for the details', and the difference between 'right URI' and
'wrong URI' is significant. A browser typically won't expose the
distinction to its user in those terms, but the browser should be able
to distinguish the cases.
Also, even if the distinction were indeed relevant only to caches and
crawlers, if I want to implement a crawler in Chicken, then I need to
have access to the distinct statuses. It's reasonable that the default
or simple behaviour is to blur the distinction, largely for the reason
that you suggest, but in a general-purpose client, the information needs
to be available somehow.
Also, as Jörg suggests in a message I see this one is crossing, I'm
writing testing code at this point, so need to be able to see what the
server actually said, rather than what the http-client library thinks it
intended.
As Peter says, this was clearly just an oversight in the http-client
library rather than a design decision. Thanks, Peter: I'll be able to
try the updated library shortly.
Though I understand why it was designed that way, it does feel slightly
awkward to me that I'm having to use an exception-handling mechanism to
get at this status distinction. A follow-redirects? parameter would
suit _my_ use-case very nicely, but I appreciate it may well have other
consequences for the interface. Similarly, a 'dumb' mode where the
library treated 2xx, 3xx, 4xx and 5xx statuses the same way, would work
very well for my case.
Best wishes,
Norman
--
Norman Gray : https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK