From: ludo@gnu.org (Ludovic Courtès)
To: Daniel Hartwig <mandyke@gmail.com>
Cc: 12827@debbugs.gnu.org
Subject: bug#12827: [2.0.6] web client: fails to parse 404 header
Date: Sat, 10 Nov 2012 14:52:15 +0100 [thread overview]
Message-ID: <87390h4lbk.fsf@gnu.org> (raw)
In-Reply-To: <CAN3veRcp=GAyXuNzD0QSMmwsvhsgN0GmR3_UmZzdQ4WP0dL5Yw@mail.gmail.com> (Daniel Hartwig's message of "Sat, 10 Nov 2012 09:45:14 +0800")
Hi,
Daniel Hartwig <mandyke@gmail.com> skribis:
> On 10 November 2012 04:52, Ludovic Courtès <ludo@gnu.org> 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.
Yes.
>>> 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.
Yes, but when the user sets #:validate? to #f, then they take the
responsibility for anything that will happen. IOW, #:validate? #f
allows users to forge broken URI objects, but that’s part of the
contract anyway.
> 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.
Good. So that means that URI refs can be added without introducing any
incompatibility.
Thanks,
Ludo’.
next prev parent reply other threads:[~2012-11-10 13:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-07 20:40 bug#12827: [2.0.6] web client: fails to parse 404 header Ludovic Courtès
2012-11-08 5:52 ` Daniel Hartwig
2012-11-08 20:10 ` Ludovic Courtès
2012-11-09 0:39 ` Daniel Hartwig
2012-11-09 20:52 ` Ludovic Courtès
2012-11-10 1:45 ` Daniel Hartwig
2012-11-10 13:52 ` Ludovic Courtès [this message]
2012-11-23 22:19 ` Ludovic Courtès
2012-11-24 11:23 ` Daniel Hartwig
2012-11-24 15:10 ` Ludovic Courtès
2012-11-24 15:34 ` Daniel Hartwig
2012-11-26 0:15 ` Ludovic Courtès
2012-11-26 23:13 ` Ludovic Courtès
2012-11-27 1:06 ` Daniel Hartwig
2012-11-27 12:50 ` Ludovic Courtès
2012-11-27 15:18 ` Daniel Hartwig
2012-11-27 21:43 ` Ludovic Courtès
2013-02-23 8:11 ` bug#12827: [PATCH] Tweak web modules, support relative URIs (was: bug#12827: [2.0.6] web client: fails to parse 404 header) Daniel Hartwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87390h4lbk.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=12827@debbugs.gnu.org \
--cc=mandyke@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).