Haig Didizian,
Check out the AOLSERVER listserv archives for the discussions with
subjects "SSL data truncation" and "differences between ns_httppost and
sockets?"
I'll post the final point, here I made earlier, but for more insight to
the problem see those threads.
Am 04.02.10 11:46, schrieb Torben Brosten:
> John Caruso et al,
>
> Could xotcl-core[2] be the work around/solution to this SSL
> ns_httpsget bug[1]?
The mentioned bug [1] looks like a buffering problem to me.
Since OpenSSL has its own buffering layer, the interaction
can be tricky and might as well differ depending on the OpenSSL
version. It has been a while, since i fiddled with this in another
context (pound + streaming connections).
I am not aware of the problem in the tls implementation,
but we are not using tls intensively. In general, the http-client
functions of xotcl-core provide an alternative
http/https implementation based directly on the Tcl I/O
functionality. So, this is indeed a different integration
with OpenSSL, which can be tested/debugged also outside
of aolserver.
While the aolserver built-in functions work
mostly without add-ons (nsopenssl), xotcl-core functions require
(1) the tcl thread library (in this context for event
driven I/O and mutex functionality), (2) tls
and (3) xotcl.
-gustaf neumann
>
> cheers,
>
> Torben
>
> 1. On July 15 2009 John Caruso wrote:
> > We've run into a bug with AOLserver 4.5.1 / nsopenssl 3.0beta26. The
> > bug is fully documented here:
> >
> >
>
https://sourceforge.net/tracker/?func=detail&aid=2822117&group_id=3152&atid=103152
>
> >
> >
> > But the short version is that when using the nsopenssl client-side
> > routines (e.g. ns_httpsget), the result may be truncated if the
> > client starts reading before all of the data has been received. This
> > bug ONLY occurs with an AOLserver client (any version) running
> > against an AOLserver 4 / nsopenssl 3.0beta26 server. We've
> > reproduced the bug on RHEL4, RHEL5, and Mac OS X.
> >
> > The bug is easily demonstrated by copying the file I've attached to
> > this message (sslbug.tcl) to the top-level context of a web server
> > running AOLserver 4.x/nsopenssl 3.0beta26 and then navigating to
> > https://<server>/sslbug.tcl. If you comment out the ns_httpsget and
> > use ns_httpget instead, you'll see that the bug disappears.
> >
> > We've done a lot of instrumenting of nsopenssl/AOLserver, but haven't
> > been able to track down the root cause. It seems likely that it's
> > related to data buffering, which seems like it would be occurring
> > within AOLserver or Tcl...but the issue is definitely specific to
> > SSL, which implies that it's something in nsopenssl 3.0beta26.
> >
> > Does anyone have any idea what might be causing this problem?
> >
> > - John
> >
> >
> > -- AOLserver - http://www.aolserver.com/
> >
> > To Remove yourself from this list, simply send an email to
> > <lists...@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in
> > the email message. You can leave the Subject: field of your email
> > blank.
>
>
>
> 2. On Feb 4, 2010, at 1:21 AM, Gustaf Neumann wrote:
>
>> Dear Brian and all,
>>
>> xotcl-core of OpenACS contains a full set of HTTP client
>> support, including POST requests and https (via the
>> tcl tls package). Below is the description included in the
>> source ....
>>
>> best regards
>> -gustaf neumann
>>
>> ===============================================
>>
>> # Defined classes
>> # 1) HttpCore (common base class)
>> # 2) HttpRequest (for blocking requests + timeout support)
>> # 3) AsyncHttpRequest (for non-blocking requests + timeout support)
>> # 4) HttpRequestTrace (mixin class)
>> # 5) Tls (mixin class, applicable to various protocols)
>> #
>> ######################
>> #
>> # 1 HttpRequest
>> #
>> # HttpRequest is a class to implement the client side
>> # for the HTTP methods GET and POST.
>> #
>> # Example of a GET request:
>> #
>> # set r [::xo::HttpRequest new -url http://www.openacs.org/]
>> #
>> # The resulting object $r contains all information
>> # about the requests, such as e.g. status_code or
>> # data (the response body from the server). For details
>> # look into the output of [$r serialize]. The result
>> # object $r is automatically deleted at cleanup of
>> # a connection thread.
>> #
>> # Example of a POST request with a form with var1 and var2
>> # (providing post_data causes the POST request).
>> #
>> # set r [::xo::HttpRequest new \
>> # -url http://yourhost.yourdomain/yourpath \
>> # -post_data [export_vars {var1 var2}] \
>> # -content_type application/x-www-form-urlencoded]
>> #
>> # More recently, we added timeout support for blocking http
>> # requests. By passing a timeout parameter, you gain control
>> # on the total roundtrip time (in milliseconds, ms):
>> #
>> # set r [::xo::HttpRequest new \
>> # -url http://www.openacs.org/ \
>> # -timeout 1500]
>> #
>> # Please, make sure that you use a recent distribution of tclthread
>> # ( > 2.6.5 ) to have the blocking-timeout feature working
>> # safely. This newly introduced feature makes use of advanced thread
>> # synchronisation offered by tclthread that needed to be fixed in
>> # tclthread <= 2.6.5. At the time of this writing, there was no
>> # post-2.6.5 release of tclthread, hence, you are required to obtain a
>> # CVS snapshot, dating at least 2008-05-23. E.g.:
>> #
>> # cvs -z3 -d:pserver:anonym...@tcl.cvs.sourceforge.net:/cvsroot/tcl
>> co \
>> # -D 20080523 -d thread2.6.5~20080523 thread
>> #
>> # Provided that the Tcl module tls (see e.g.
>> http://tls.sourceforge.net/)
>> # is available and can be loaded via "package require tls" into
>> # the aolserver, you can use both TLS/SSL secured or unsecured
>> requests
>> # in the synchronous/ asynchronous mode by using an
>> # https url.
>> #
>> # set r [::xo::HttpRequest new -url https://learn.wu-wien.ac.at/]
>> #
>> ######################
>> #
>> # 2 AsyncHttpRequest
>> #
>> # AsyncHttpRequest is a subclass for HttpCore implementing
>> # asynchronous HTTP requests without vwait (vwait causes
>> # stalls on aolserver). AsyncHttpRequest requires to provide a
>> listener
>> # or callback object that will be notified upon success or failure of
>> # the request.
>> #
>> # Asynchronous requests are much more complex to handle, since
>> # an application (a connection thread) can submit multiple
>> # asynchronous requests in parallel, which are likely to
>> # finish after the current request is done. The advantages
>> # are that the spooling of data can be delegated to a spooling
>> # thead and the connection thread is available for handling more
>> # incoming connections. The disadvantage is the higher
>> # complexity, one needs means to collect the received data.
>> #
>> #
>> # The following example uses the background delivery thread for
>> # spooling and defines in this thread a listener. This generic
>> # listener can be subclasses in applications.
>> #
>> # When using asynchronous requests, make sure to specify a listener
>> # for the callbacks and delete finally the request object in the
>> # bgdelivery thread.
>> #
>> # ::bgdelivery do ::xo::AsyncHttpRequest new \
>> # -url "https://oacs-dotlrn-conf2007.wu-wien.ac.at/conf2007/"; \
>> # -mixin ::xo::AsyncHttpRequest::SimpleListener
>> # -proc finalize {obj status value} { my destroy }
>> #
>> ######################
>> #
>> # 3 HttpRequestTrace
>> #
>> # HttpRequestTrace can be used to trace one or all requests.
>> # If activated, the class writes protocol data into
>> # /tmp/req-<somenumber>.
>> #
>> # Use
>> #
>> # ::xo::HttpCore instmixin add ::xo::HttpRequestTrace
>> #
>> # to activate trace for all requests,
>> # or mixin the class into a single request to trace it.
>> #
>>
Haig Didizian wrote:
> Hello there,
>
> We use a handful of web services in running our ecommerce site, and
they use ns_httpspost (from https.tcl) to post SOAP data. Since this one
integration went live about 6 months ago, we've been noticing that
occasionally a request would hang up the page. What I notice is that
aolserver triggers the following error in our logs while posting the
request:
>
> Warning: nsopenssl (instancename): SSL write interrupted: unexpected eof
>
> This error doesn't bubble up to ns_httpsopen in a way that it can
catch, so that function then waits forever for a response from the
server. Unrequited SOAP is so tragic...
>
> As an aside, I'm using the nsopenssl I picked up from SourceForge --
called "nsopenssl-3.0beta26". Is that the best choice?
>
> I did some digging and realized that the "unexpected eof" message is
triggered when SSL_write (in NsOpenSSLConnOp) returns 0, which it's
doing because it's told to write 0 bytes by ChanOutputProc. This only
happens intermittently, so I assume the data being posted is some magic
length. It would probably be best to figure out why that function is
being called when there's no data left to write, but I went with a
really simple fix that prevents NsOpenSSLConnOp from being called in
that case. Patch attached.
>
> Thanks,
> Haig
>
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
