bug#12827: [PATCH] Tweak web modules, support relative URIs

[Daniel Hartwig <mandyke@gmail.com>]

On 24 February 2013 18:45, Mark H Weaver <mhw@netris.org> wrote:
> Hi Daniel,
>
> Daniel Hartwig <mandyke@gmail.com> writes:
>> * Terminology
>>
>> The terminology used in latest URI spec. (RFC 3986) is not widely used
>> elsewhere.  Not by Guile, not by the HTTP spec., or other sources.
>> Specifically, it defines these terms:
>>
>> - URI: scheme rest ... [fragment]
>> - Absolute-URI: scheme rest ... [fragment]
>> - Relative-Ref: rest ... [fragment]
>> - URI-Reference: Absolute-URI | Relative-Ref
>>
>> where as HTTP and other sources use the terms from an earlier URI
>> spec. (RFC 2396):
>>
>> - Absolute-URI: scheme rest ... [fragment]
>> - Relative-URI: rest ... [fragment]
>> - URI, URI-Reference: Absolute-URI | Relative-URI
>>

> My preference would be to use the newer RFC 3986 terms.  To my mind, the
> key question is: which type (Absolute-URI or URI-Reference) is more
> commonly appropriate in user code, and thus more deserving of the short
> term "URI".
>
> I would argue that Absolute-URIs are more often appropriate in typical
> user code.  The reason is that outside of URI-handling libraries, most
> code that deals with URIs simply use them as universal pointers,
> i.e. they implicitly assume that each URI is sufficient by itself to
> identify any resource in universe.

Right.  RFC 3986 makes a convincing argument for the new terminology.
These notes about usage also reflect the sentiment in that document.

FWIW, I sat mostly on the fence, finally going away from URI-Reference
due to these concerns I expressed in an earlier email:
> The API seems less clean, and it is not immediately clear
> that uri? is not the top of the URI-like type hierarchy.  The other
> functions only indicate “uri” in their name.  I did not
> wish to introduce parallel “build-uri-reference”, etc. for each of
> these, and did consider adding #:reference? on some to select
> weaker validation.

and looking at some other Scheme URI modules.

However, having read over your comments I think that we could
reasonably get away with just introducing the procedures you mention
below and not bother about renaming (or duplicating) the field getters
to ‘uri-reference-path’ etc..

> Here's what I suggest: instead of extending 'string->uri' and
> 'build-uri' to produce relative URIs, rename those extended procedures
> 'string->uri-reference' and 'build-uri-reference'.  These are long
> names, but that's okay because users should think twice before using
> them, and that's seldom needed.

In your proposed solution, ‘uri?’ and ‘uri-reference?’ are the
predicates and they respond according to the RFC rather than internal
Guile details?  That is:

  (uri? (string->uri-reference "http://example.net/"))
  => #t
  (uri-reference? (string->uri-reference "http://example.net/"))
  => #t
  (uri? (string->uri-reference "foo"))
  => #f

or …?

> Then, we extend 'string->uri' and 'build-uri' in a different way: we
> extend them to handle relative references in their *inputs*, but
> continue to provide absolute *outputs*, by adding an optional keyword
> argument '#:base-uri'.  This would make it easy to implement the
> simplest and safest strategy outlined above with a minimum of code
> changes.

This strategy does reflect the recommendation of RFC 3986 to resolve
the references as they are read.  Also an elegant API, as it
encourages immedately resolving uri-references and never creating (or
considering to create) the context-sensitive relative-refs.

>
> What do you think?
>

I quite like it, particularly the last part about #:base-uri.

Ludo, I think this is basically what you were suggesting in the first place? :-)

.