[racket] Preventing get-impure-port from url-encoding the query

I'd agree that a string and/or bytes value supplied as a query
component would be the best solution. Let us shoot ourselves in our
feet!
In terms of a comprehensive url api, I think the argument would be
that application/x-www-form-urlencoded query strings are the most
common use case, but certainly are not a requirement for the query
component in urls.

(In this particular case, I would also concur that the burden is on
the web application to be able to handle form-urlencoded query
strings, but I sympathize. In a past project, also at a major
university, an authentication url required an unusually formatted
"return url" format, where ampersands were replaced with dollar signs,
but all else was left intact. This was an ad-hoc encoding, for sure,
but since the authenticating side was much more restricted in terms of
development agility, we were the ones who adapted...)

On Thu, Jul 11, 2013 at 5:21 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:
> Even and I spoke offline, and although I don't have all the details (and
> something sounds odd), it currently sounds like the core problem here is
> that some server program (perhaps not stock Shibboleth itself) is unusually
> non-compliant in its handling of URLs.[*]
>
> Although the problem here does not appear to be in Racket, it wouldn't hurt
> to modify "net/url" to permit a verbatim HTTP request path and query
> components to be specified as an optional string/bytes argument, separate
> from the URL argument.  (Alternatively, you could do less aggressive
> "%"-encoding of the query and fragment parts of the URL than you do for the
> path, although that risks breaking *different* broken server software.  And
> you shouldn't *have* to be less aggressive.)
>
> [*] I have implemented support for around a dozen different single-signon
> Web authentication systems (lots of organizations do it differently, despite
> SAML), incidental to my consulting practice, and usually I only run into
> this kind of quirky behavior when dealing with HTTP proxies/firewalls, not
> with IdPs or other authentication servers.
>
>
> Neil
>
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users



-- 
Erik Pearson
Adaptations
;; web form and function