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/andresgarci/tclcurl/english/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:[EMAIL PROTECTED] 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:
>> Dossy Shiobara wrote:
>>>> What I'm struggling with though is if I store an image file to the
>>>> sob with sob.copy and then try and retrieve it later with nsob.get,
>>>> it only returns the first 4 or 10 bytes of the file.
>>>
>>> SOB isn't encoding-aware and is actually really naive--it doesn't  
>>> handle
>>> binary data well.
>>
>> Not sure if this it related, but I was just looking at ns_http for an
>> unrelated purpose and it appears that it is not binary clean at all,
>> since it uses Tcl_SetVar which expects a null-terminated string.
>> Getting binary files typically resulted in a 4 byte response,  
>> could be
>> that an average jpg file has a null at byte 4.
>>
>> -J
>>
>>
>> --
>> AOLserver - http://www.aolserver.com/
>>
>> To Remove yourself from this list, simply send an email to
>> <[EMAIL PROTECTED]> 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  
> <[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to