[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12827: [2.0.6] web client: fails to parse 404 header
From: |
Daniel Hartwig |
Subject: |
bug#12827: [2.0.6] web client: fails to parse 404 header |
Date: |
Sat, 10 Nov 2012 09:45:14 +0800 |
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
- bug#12827: [2.0.6] web client: fails to parse 404 header, Ludovic Courtès, 2012/11/07
- bug#12827: [2.0.6] web client: fails to parse 404 header, Daniel Hartwig, 2012/11/08
- bug#12827: [2.0.6] web client: fails to parse 404 header, Ludovic Courtès, 2012/11/23
- bug#12827: [2.0.6] web client: fails to parse 404 header, Daniel Hartwig, 2012/11/24
- bug#12827: [2.0.6] web client: fails to parse 404 header, Ludovic Courtès, 2012/11/24
- bug#12827: [2.0.6] web client: fails to parse 404 header, Daniel Hartwig, 2012/11/24
- bug#12827: [2.0.6] web client: fails to parse 404 header, Ludovic Courtès, 2012/11/25
- bug#12827: [2.0.6] web client: fails to parse 404 header, Ludovic Courtès, 2012/11/26
- bug#12827: [2.0.6] web client: fails to parse 404 header, Daniel Hartwig, 2012/11/26
- bug#12827: [2.0.6] web client: fails to parse 404 header, Ludovic Courtès, 2012/11/27
- bug#12827: [2.0.6] web client: fails to parse 404 header, Daniel Hartwig, 2012/11/27