[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] POST and GET request parameters from spiffy

From: Stephen Eilert
Subject: Re: [Chicken-users] POST and GET request parameters from spiffy
Date: Tue, 8 Dec 2009 13:44:00 -0300

On Tue, Dec 8, 2009 at 1:17 PM, Peter Bex <address@hidden> wrote:
On Tue, Dec 08, 2009 at 12:52:00PM -0300, Stephen Eilert wrote:
> A few days ago I had a difficult bug to diagnose, which happened because I
> was trying to use uri-generic with uri-dispatch, instead of uri-common.
> What is the purpose of uri-generic anyway?

It is an implementation of RFC 3986, which is much more broadly
applicable than just in web URIs.  For example, URNs like
urn:ietf:rfc:3986 are also URIs, but not URI-commons.  They have
no authority (user/pass/hostname/port combination), and no query
string either, only a path.  Some other schemes *do* have query
strings, but not x-www-form-urlencoded ones.

The uri-generic egg is intended for handling the full generality
of all these types of URIs, whereas uri-common is intended for the
specific "common" subset of URIs which are usually used on the web,
to indicate a host, port and path indicating a resource on that host,
with optionally an x-www-form-urlencoded query to pass to that resource
for further processing.

uri-common adds a few extra conveniences like more complete path
decoding (all percent-encoded bits are fully decoded) because it knows
this is allowed since the path's components are separated by slashes
but have no additional separators with special meaning inside.  Other
schemes can't be handled this way.  For example, the URN scheme
mentioned above has a colon (:) which has special meaning, so %3A could
not be decoded into : until after the parts are separated;
urn:foo%3Abar:qux  would be decoded to "foo:bar:qux", and hence it would
be indistinguishable from urn:foo:bar:qux.

So, to summarize: you would never need or use uri-generic unless you're
writing a more specific URI parser for other schemes than the common

Thanks for the explanation.


programmer, n:
       A red eyed, mumbling mammal capable of conversing with inanimate monsters.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]