unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Daniel Hartwig <mandyke@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 12827@debbugs.gnu.org
Subject: bug#12827: [2.0.6] web client: fails to parse 404 header
Date: Sat, 10 Nov 2012 09:45:14 +0800	[thread overview]
Message-ID: <CAN3veRcp=GAyXuNzD0QSMmwsvhsgN0GmR3_UmZzdQ4WP0dL5Yw@mail.gmail.com> (raw)
In-Reply-To: <874nky7b2v.fsf@gnu.org>

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.

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





  reply	other threads:[~2012-11-10  1:45 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 [this message]
2012-11-10 13:52           ` Ludovic Courtès
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='CAN3veRcp=GAyXuNzD0QSMmwsvhsgN0GmR3_UmZzdQ4WP0dL5Yw@mail.gmail.com' \
    --to=mandyke@gmail.com \
    --cc=12827@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /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).