Re: [AOLSERVER] nsdci query
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.
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 client choices in AOLServer (was: RE: [AOLSERVER] nsdci query)
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.
Re: [AOLSERVER] nsdci query
Michael Andrews wrote: I think the ns_http bug was fixed in the HEAD by Nate. *ashamed* Yeah, the code I'm looking at is 4.0.8, pretty old. I probably just need to upgrade and this will work better. -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.
Re: [AOLSERVER] HTTP client choices in AOLServer (was: RE: [AOLSERVER] nsdci query)
On 2007.10.23, Rick Cobb [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | 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) -- 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.
Re: [AOLSERVER] HTTP client choices in AOLServer (was: RE: [AOLSERVER] nsdci query)
On Tuesday 23 October 2007 09:07, Rick Cobb wrote: 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) This isn't quite accurate. What is going on in ns_http, is that a single thread does socket operations. When you do a ns_http queue, it places the request in a queue in this thread (different than a connection thread). The [ns_http queue] returns an id used during [ns_http wait]. [ns_http wait] can be called in a separate thread, like a scheduled proc. So you don't have to pass a socket around, it always remains in the queue thread. Also, you can add headers in a similar way to a regular request. That is, you provide a ns_set with additional headers. So whatever auth methods are supported with headers, you can do with ns_http. There is also ns_httpsget/post which handles https, just like ns_httpget/post. The commands ns_httpopen/ns_httpsopen are use by the get/post indirectly. I also think these may follow redirects. tom jackson -- 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.
Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
I've been working on a slightly different angle here, trying to avoid thread exit, and to allow threads to range usefully between min and max. The current code in CVS has a number of problems which lead to the server not creating more threads when there are queued requests and the number of threads is below max (sometimes below min!). Now my test code has solved most of these issues. 1. threads go up very quickly to with load increase. 2. threads go down when load goes down (if queue is kept empty) to slightly below concurrency. 3. if maxthreads is lowered, threads slowly go down to meet the new value. There are still a few things I'd like to look at, so I'll hold off on any commit for now. tom jackson On Monday 22 October 2007 16:04, Gustaf Neumann wrote: Andrew Piskorski schrieb: My only point here was that I'm going to stop looking at the timeout parameter, and timed out threads as an issue. If threads timeout, the number of threads in a threadpool will drop below minthreads, usually to zero. But isn't that a bug? If not, just what is minthreads supposed to really mean? you are right, if someone specified minthreads, they should be maintained. i have added an additional condition to the thread recreation to maintain the specified minimal number of threads. maybe Tom has something more sophisticated in mind. this is again a minimal invasive fix, similar to the fix for assuring the processing of the queued requests, when all connection threads exit. for more details, see: http://aolserver.cvs.sourceforge.net/aolserver/aolserver/nsd/queue.c?view=l og best regards -gustaf neumann -- 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.
