GNU bug report logs - #12827
[2.0.6] web client: fails to parse 404 header

Previous Next

Full log

Message #35 received at 12827 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Hartwig <mandyke <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 12827 <at> debbugs.gnu.org
Subject: Re: bug#12827: [2.0.6] web client: fails to parse 404 header
Date: Sat, 24 Nov 2012 23:34:41 +0800

On 24 November 2012 23:10, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> Personally I am not 100% on this, but I attach it for comment anyway.
>> I will not be able to work on it again for a short while.
>>
>> A quick solution may be to silently introduce just enough to fix the
>> current bug, and worry about the extra predicates, uri-record-type vs.
>> rfc-definition-of-uri, etc. later.
>
> I could come up with a ‘declare-relative-uri-header!’ that would use
> (build-uri xxx #:validate? #f) as a quick fix.
>
> However, it seems to me that your patch is actually fine, and doesn’t
> break compatibility, so I’d rather apply it directly.  Did you have
> other concerns?

The API seems less clean, and it is not immediately clear
that uri? is not the top of the URI-like type hierarchy.  The other
functions only indicate “uri” in their name.  I did not
wish to introduce parallel “build-uri-reference”, etc. for each of
these, and did consider adding #:reference? on some to select
weaker validation.

I think I prefer to keep the base type predicate as uri?, and use
relative-ref? and absolute-uri? to distinguish.  This would mean
deviating from the RFC by:
- permitting fragments in absolute-uri?;
- not requiring a scheme in uri?;

which are both forgivable.

Maybe I am just too fussy!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.