[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: |
Ludovic Courtès |
Subject: |
bug#12827: [2.0.6] web client: fails to parse 404 header |
Date: |
Fri, 09 Nov 2012 21:52:56 +0100 |
User-agent: |
Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) |
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’.
- 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