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

[Daniel Hartwig]

On 10 November 2012 04:52, Ludovic Courtès <address@hidden> wrote:
> Anyway, I think it’s fine if the documentation makes it clear whether
> functions expect absolute or relative URIs.  WDYT?

Yes.  With the new predicates, it should be clear enough to use the
(pseudo-)type names in the usual scheme-doc way:

  -- Scheme Procedure: uri-resolve base-uri uri-reference

and not need to repeat too much in the prose.  Of course, doing so
when appropriate.  I'll try to draft something sensible.

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

More-or-less, the only exception being when validation is disabled:

scheme@(guile-user)> (uri? (build-uri #f #:path "foo" #:validate? #f))
$1 = #t

that object has no scheme, and is not an absolute-uri.  This is a bit
of an edge case.

The current documentation only defines a URI as an absolute-uri and
does not talk about anything else.  Most functions (uri->string, etc.)
will not work when passed something without a scheme.  So I think your
suggestion is ok as any users of the current API will most certainly
be using only absolute-uri's.

Regards