AOL Webserver - HTTP client choices in AOLServer (was: RE: [AOLSERVER] nsdci query)

Author

HTTP client choices in AOLServer (was: RE: [AOLSERVER] nsdci query)

Rick Cobb

2007-10-23, 1:11 pm

It seems to me like in AOLServer 4, we have four ways for Tcl code to
behave as an HTTP client. Has anybody done any compare & contrast on
them? As far as I can tell without a lot of code experience on some of
them, we have:

ns_http{open,get,post}
Generally synchronous
Only supports GET and POST
Only supports BASIC auth
No proxy support
No SSL (https) support
Implemented entirely in Tcl
Best compatibility (available in AOLServer 2 - 4)
Built-in
Only usable from a single thread (no channel/socket passing)

ns_http (http://panoptic.com/wiki/aolserver/Ns_http)
Supports asynchronous operation
Supports all methods
Only supports BASIC auth
No proxy support
No SSL (https) support
Implemented largely in C
Available only in AOLServer 4 and above
Built-in
Only usable from a single thread (no channel/socket passing)

Tcl's HTTP package (the one I know the least about)

Supports asynchronous operation with progress callbacks
Supports GET, POST, and HEAD
Not obvious how to use any authentication other than BASIC
Supports proxy on a per-call basis (but you're responsible for .pac
translation if necessary).
Supports TLS/SSL (via callback)
Somewhat more complicated API to use than the above options
Built-in since Tcl 7?

TclCurl
(http://personal1.iddeo.es/andresgar...glish/docs.html)
Supports asynchronous operation
Supports GET and POST, not clear about others but don't look
supported
Supports BASIC, DIGEST, GSS-Negotiate, NTLM
Supports proxy on a per-call basis (but you're responsible for .pac
translation if necessary)
Implemented in C
Requires packaging work (bringing it into your Tcl & AOLServer
build)
Multi-threading requires config / build - time work (c-ares)
Passing handle between threads requires wrapping in your own mutex
Supports FTP, telnet, other common URLs
Substantially more complicated API to use than the other options

So, for example, if I want to communicate with a RESTful application
(i.e., uses PUT, DELETE, etc) over HTTPS, it looks like there is no
option. Of course, most such applications also provide a POST wrapper,
but didn't the way-back Navi/AOLServer team have a solution for this?

Thanks --
-- ReC

-----Original Message-----
From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf
Of Michael Andrews
Sent: Tuesday, October 23, 2007 7:44 AM
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] nsdci query

I think the ns_http bug was fixed in the HEAD by Nate.

On Oct 23, 2007, at 9:31 AM, Tom Jackson wrote:

> Jeff,
>
> I have ns_http working, at least for me here with binary data.
> Supposedly this
> is the reason for ns_http (not ns_httpget/post or ns_httpsget/post):
>
> Here is a script:
>
> set id [ns_http queue http://192.168.1.102:8000/sns-thumb.jpg]
>
> set ok [ns_http wait -result image -status status $id]
>
> if {"$status" == "200"} {
> set fd [open [file join [file dirname [info script]]
> myimage.jpg] w+]
> } else {
> ns_return $status text/html $image
> return -code return
> }
>
> # Very important:
> fconfigure $fd -translation binary
>
> puts $fd $image
>
> close $fd
>
> ns_return $status text/html "Status: $status <br>
> <a href=\"/myimage.jpg\">My Image</a>"
>
>
>
>
> On Monday 22 October 2007 18:08, Jeff Rogers wrote:
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the
> Subject: field of your email blank.

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.

Dossy Shiobara

2007-10-23, 7:11 pm

On 2007.10.23, Rick Cobb <rcobb@KNOWNOW.COM> wrote:
> So, for example, if I want to communicate with a RESTful application
> (i.e., uses PUT, DELETE, etc) over HTTPS, it looks like there is no
> option. Of course, most such applications also provide a POST wrapper,
> but didn't the way-back Navi/AOLServer team have a solution for this?

As part of the nsopenssl module, there are (IMHO, broken)
implementations of ns_httpsopen and friends.

I think TclCurl will do SSL if the underlying libcurl is compiled with
support for it, too.

-- Dossy

--
Dossy Shiobara | dossy@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

Tom Jackson

2007-10-23, 7:11 pm

On Tuesday 23 October 2007 09:07, Rick Cobb wrote:
> ns_http (http://panoptic.com/wiki/aolserver/Ns_http)
> =A0 =A0 =A0Supports asynchronous operation
> =A0 =A0 =A0Supports all methods
> =A0 =A0 =A0Only supports BASIC auth
> =A0 =A0 =A0No proxy support
> =A0 =A0 =A0No SSL (https) support
> =A0 =A0 =A0Implemented largely in C
> =A0 =A0 =A0Available only in AOLServer 4 and above
> =A0 =A0 =A0Built-in
> =A0 =A0 =A0Only usable from a single thread (no channel/socket passing)

This isn't quite accurate.=20

What is going on in ns_http, is that a single thread does socket operatio=
ns.=20
When you do a ns_http queue, it places the request in a queue in this thr=
ead=20
(different than a connection thread).

The [ns_http queue] returns an id used during [ns_http wait]. [ns_http wa=
it]=20
can be called in a separate thread, like a scheduled proc. So you don't h=
ave=20
to pass a socket around, it always remains in the queue thread.=20

Also, you can add headers in a similar way to a regular request. That is,=
you=20
provide a ns_set with additional headers. So whatever auth methods are=20
supported with headers, you can do with ns_http.=20

There is also ns_httpsget/post which handles https, just like ns_httpget/=
post.=20
The commands ns_httpopen/ns_httpsopen are use by the get/post indirectly.=
I=20
also think these may follow redirects.

tom jackson=20

John Caruso

2007-10-25, 7:11 pm

On Tuesday 10:30 AM 10/23/2007, Dossy Shiobara wrote:
>As part of the nsopenssl module, there are (IMHO, broken)
>implementations of ns_httpsopen and friends.

Could you expand on what you think is broken about them?

- John

Dossy Shiobara

2007-10-25, 7:11 pm

On 2007.10.25, John Caruso <jcaruso@ARENASOLUTIONS.COM> wrote:
> On Tuesday 10:30 AM 10/23/2007, Dossy Shiobara wrote:
>
> Could you expand on what you think is broken about them?

At AOL, a team that was using them had run into some kind of hang issue
where a blocking Tcl [read] was done on the Tcl channel (that was backed
by an nsopenssl SSL conn) that would never wake up and/or would time
out.

-- Dossy

--
Dossy Shiobara | dossy@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)