bug#12827: [2.0.6] web client: fails to parse 404 header

[Ludovic Courtès]

Hi Daniel,

Daniel Hartwig <address@hidden> skribis:

> On 9 November 2012 04:10, Ludovic Courtès <address@hidden> wrote:
>>> * TODO build-uri validation is broken/less strict and will now pass
>>> relative-refs, so maybe introduce build-uri-reference instead
>>
>> Yes.  Should uri-reference be a disjoint type, then?
>
> It needn't be, as long as there are predicates to distinguish.
> (Actually, since <uri> is internal, maybe we should only expose the
> new predicates, and keep “uri?” internal also).

I’m fine with keeping <uri> internal, but ‘uri?’ is public and must
remain so.

Anyway, I think it’s fine if the documentation makes it clear whether
functions expect absolute or relative URIs.  WDYT?

> The build-uri validation works on the values before the <uri> object
> is constructed, so I was just thinking of a separate build method with
> different, less strict validation.
>
> We just have to think of <uri> and uri? as guile implementation
> details, not RFC.  Another option, is to rename <uri> to
> <uri-reference>.  Then uri? can mean the same as absolute-uri? (as per
> the RFC).

Out current URI objects are actually absolute URI references, right?  In
that case, we’ll indeed have to make ‘uri?’ synonymous with
‘absolute-uri?’, for backward compatibility.

>>> @@ -1729,7 +1736,7 @@ treated specially, and is just returned as a plain 
>>> string."
>>>
>>>  ;; Referer = ( absoluteURI | relativeURI )
>>>  ;;
>>> -(declare-uri-header! "Referer")
>>> +(declare-uri-reference-header! "Referer")
>>
>> Should actually be “Referrer”, no?
>
> This is the actual spelling used in the RFC.

Ouch.

>> Eventually, we’ll need docstrings, and updated documentation.
>
> Yes.  I lazily left that until the other parts are finalized.  Let me
> tackle the remaining items over the next week.

Yes, sure.

Thanks!

Ludo’.