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

[Daniel Hartwig]

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

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

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

If we had those docs and the naming is ok, this patch is enough to
support reading the HTTP headers.  Users of http-get should be sure to
pass only an absolute-uri.  The missing function to resolve a
relative-ref to an absolute-uri is not required for reading or writing
headers, or using http-get, so that can come later (maybe I get this
week anyway).

Regards