On Sun, Apr 07, 2019 at 06:06:11PM +0300, Lassi Kortela wrote:
> Your API looks good to me. I.e. the keyword arguments (is that the right
> term in Scheme?) are the same as the ones for the constructor, and you only
> give the ones you want to change.

Yeah, they're keywords.  Those aren't part of RnRS Scheme though, it's an
extension (which CHICKEN took from DSSSL).

I seem to recall there's a standard port of uri-generic somewhere which
uses symbols instead.  So, (update-uri u 'scheme 'https) and such.

> > In uri-common, there's a SRFI-39 parameter you can set (fluidly or
> > globally) which controls this.
>
> Do you mean `(define form-urlencoded-separator (make-parameter ";&"))`?

yeah; setting it globally would be (form-urlencoded-separator ";") and
fluidly would be (parameterize ((form-urlencoded-separator ";")) ...)

> > Otherwise, it'd make more sense to have uri->string accept the separator
> > and other options.
>
> OK, I'm trying to comprehend the situation in its full glory and it's
> getting painful :D
>
> Maybe we should store only the raw query string from the server.
>
> And the separators ";&" would be given separately to each call of the query
> parameter list getter. I.e.:
>
>     (uri-raw-query-string u)       == "a%3Db;c=d&e=f"
>     (uri-query/delimiters u ";&")  == (("a" . "b")
>                                        ("c" . "d") ("e" . "f"))

I don't like this; it would require parsing and re-parsing every time
you access the query alist.  Maybe we can make it another parameter for
the constructor so it's stored inside the uri object?  That way, we can
split it when parsing and combine it when constructing the underlying
raw string.

> The constructor and update procedure "path:" arguments would use the
> conservative delimiters to encode the path, and raise an error if those
> delimiters appear in the user-supplied strings:
>
>     (set! u (make-http-uri path: '("foo")))
>     (update-uri u :path '("foo" "bar"))
>
>     (update-uri u :path '("foo" "/" "bar"))
>        ;; this would error because we cannot unambiguously encode slash

Slash is the one thing you can unambiguously encode (because you're
already separating components on slashes, slashes _must_ be encoded as
%2F in path components), but giving an error seems rather unfriendly.

The way we handle it in uri-common is to simply encode as much as
possible.  When that's not desired, you must update the raw path,
instead.

> > I don't think you need to be able to dispatch on the query _string_,
> > only on the parsed values.
>
> That still seems quite specialized. But if we can parse the query parameters
> into a canonical "safe" normal form then I don't see a problem with
> dispatching on them.

Yeah, that should be safe and fine.

> > I don't really see the value in that.  foo//bar is not the same path
> > as foo/bar.  A web server could issue a 301 redirect to "fix" such
> > paths, which I think is a better level at which to fix it.
>
> OK, you know much better than I do what the usual convention is.

Well, the usual convention is whatever other languages do, which tend
to just ignore all these issues ;)

Cheers,
Peter