[racket-dev] net/url and https

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Sun Jun 19 18:26:03 EDT 2011

I think we should not remove anything from the net/url library
(including the unitized interface) as I believe that will break old
code.

Robby

On Mon, Jun 20, 2011 at 5:57 AM, Eli Barzilay <eli at barzilay.org> wrote:
> Does anyone have any objection to dropping the unitized interface for
> `net/url'?  Specifically, did anyone ever used it for any purpose
> other than making up an `ssl:*' variant of the library?
>
> I'm looking into making it deal properly with ssl connections, and I
> think that the right way to do it is by making the code dispatch to
> the plain tcp functions or the ssl versions based on the scheme of the
> input url.
>
> 1. Looking at the code, there are only two tcp functions used
>   (`tcp-connect' and `tcp-abandon-port'), so eliminating the unit
>   interface and just hooking things up so that an "https" scheme uses
>   the ssl functions is relatively easy.
>
> 2. Another possibly solution is to make the `net/url-unit' import two
>   tcp units, one for plain connections and one for https connextions.
>   The problem with that is that it still breaks compatibility since
>   the imports are different.
>
> 3. Yet another solution is to make it do the same thing it does now,
>   but for "https" urls it will always use the ssl bindings.  This
>   means that you can still parameterize the code over the tcp
>   functions, but "https" urls bypass that parameterization and use
>   the ssl things directly.
>
> I dislike #2 since it's making things even more hairy in the unit
> sense, and I don't think that that's a good direction.  I dislike #3
> since it feels like a bad hack.
>
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>



Posted on the dev mailing list.