[racket-dev] net/url and https

15 minutes ago, Robby Findler wrote:
> I think we should not remove anything from the net/url library
> (including the unitized interface) as I believe that will break old
> code.

This means one of 2.5 new options:

  4. Create a new library that will do exactly what `net/url' is
     doing, except without the unit interface (or the two-tcp-imports
     interface), and with the desired dispatching over "https" urls.

  5. Create a new library that will do the right thing, extending what
     net/url does by a whole bunch of stuff.  That means a complete
     redesign of the library.

  6. Do #4 first, then do #5.

I think that #5 is inevitable.  The `net/url' is designed in a way
that dooms it to be a toy.  For example, it just gives you the
contents, possibly with the HTTP reply headers pretty much as is --
which means that there is no way to distinguish a 404 result (should
result in an error) or a 301 result (should follow the redirection).
To properly deal with these things, you currently need to manually
look at the impure port and parse it yourself.  Further, there's a
bunch of additional functionality that is missing from it.

I do plan to write it (a new library, the #5 option).  Of course
unless someone else does that (*wink* *wink* *nudge* *nudge*).  It
might even be compatible with the current `net/url', but probably not
with the unit part.

Given that there is a need for such a library, #4 is not a viable
option.  However, doing this will require more time.  (Specifically, I
can change the `net/url' as previously described right now, but a new
library will probably take much more time.) This leaves #6 as the only
other alternative if there's a need to get a solution right now.  But
I dislike it, since I consider `net/url' a toy in terms of
functionality, and #6 means duplicating that toy only to solve a
problem temporarily.



> 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
> >

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!