[AOLSERVER] TLS package issue

2010-12-06 Thread aT

Hi ,

We are using the TLS package to call a certain HTTPs API, we do usually 
import the package using "package require" command then doing a normal 
"::http::register https 443 ::tls::socket"


Sometimes a strange error just appear saying that "invalid ::tls:socket 
command".


Am assuming that the issue is happening due to a failure while importing 
the TLS package and its random.. may be this is happening because the 
package is already imported and am trying to import it again? or because 
of an open sockets somewhere that should be closed? is it a bug in AOL?


We are using Aolserver 4.0.10 . TLS version is 1.6 Its a 64bit linux 
environment ,


Has any one encountered same using TLS .

Atif


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

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


[AOLSERVER] TLS package issue

2010-12-06 Thread aT

Hi ,

We are using the TLS package to call a certain HTTPs API, we do usually 
import the package using "package require" command then doing a normal 
"::http::register https 443 ::tls::socket"


Sometimes a strange error just appear saying that "invalid ::tls:socket 
command".


Am assuming that the issue is happening due to a failure while importing 
the TLS package and its random.. may be this is happening because the 
package is already imported and am trying to import it again? or because 
of an open sockets somewhere that should be closed? is it a bug in AOL?


We are using Aolserver 4.0.10 . TLS version is 1.6 Its a 64bit Linux 
environment ,


Has any one encountered same using TLS .

Atif


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

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


Re: [AOLSERVER] TLS package issue

2010-12-06 Thread Fenton, Brian
Hi Atif

I can confirm that we're running TLS 1.6 with AOLserver 4.5.1 on Suse 9.4 64 
bit and I've never seen this problem. However, we haven't tested it under heavy 
loads yet.

hope this helps
Brian Fenton


From: AOLserver Discussion [aolser...@listserv.aol.com] On Behalf Of aT 
[atif@gmail.com]
Sent: 06 December 2010 11:19
To: AOLSERVER@LISTSERV.AOL.COM
Subject: [AOLSERVER] TLS package issue

Hi ,

We are using the TLS package to call a certain HTTPs API, we do usually
import the package using "package require" command then doing a normal
"::http::register https 443 ::tls::socket"

Sometimes a strange error just appear saying that "invalid ::tls:socket
command".

Am assuming that the issue is happening due to a failure while importing
the TLS package and its random.. may be this is happening because the
package is already imported and am trying to import it again? or because
of an open sockets somewhere that should be closed? is it a bug in AOL?

We are using Aolserver 4.0.10 . TLS version is 1.6 Its a 64bit Linux
environment ,

Has any one encountered same using TLS .

Atif


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

To Remove yourself from this list, simply send an email to 
 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 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] Does not work ns_return + zlib

2010-12-06 Thread Alexey Pechnikov
I'm see the code in connio.c:

/*
 * GZIP the content when not streaming if enabled and the content
 * length is above the minimum.
 */

if (!stream
&& (conn->flags & NS_CONN_GZIP)
&& (servPtr->opts.flags & SERV_GZIP)
&& (len > (int) servPtr->opts.gzipmin)
&& (ahdr = Ns_SetIGet(conn->headers, "Accept-Encoding")) != NULL
&& strstr(ahdr, "gzip") != NULL
&& Ns_Gzip(buf, len, servPtr->opts.gziplevel, &gzip) == NS_OK) {
buf = gzip.string;
len = gzip.length;
Ns_ConnCondSetHeaders(conn, "Content-Encoding", "gzip");
}

There are no checks for content-type and older version of Internet Explorer
(IE5, IE6 and may be IE7 have a lot of problems with gzipped scripts and
styles). I don't think that this code is useful for production. And we may
add ETAG functionality and smart caching checksums of results for decreasing
data transfer and server loading. I dont know about your situation but my
clients have limited internet connections (especially on mobile devices) and
ETAG header transmitting is faster when gzipped content... For static files
on group of hosts application-defined ETAG is helpful too but internal AOL
last-modified-since mechanizm is niot useful (it's not the AOL problem, of
cource).

P.S. I dont understand why my suggestion to complete AOL documentation by
examples was produce the holywar about Tcl 8.4 vs 8.5 vs 8.6. I think AOL
4.5.1 + Tcl 8.5 is better choice for new projects and Tcl 8.6 is better for
some utilities (fast internal base64 realization, half-closed sockets and
other features help me to build faster applications with a few lines of
code). Tcl 8.6 documentation of zlib functions is much better than AOL
documentation of ns_zlib module and some of this docs and examples can be
helpful for AOL, why not?


2010/12/2 Hossein Sharifi 

> I'm pretty sure that gzip compression is already natively and transparently
> supported in AOLserver as long as you build and include the ns_zlib module.
> You shouldn't ever have to bother with encoding or calling a special
> function; rather, you just need to enable it in the config file: "ns_param
> gzip on" in the ns/server/${server} section of your config file (there's
> also a gzipmin param to set the minimum size required in bytes to trigger
> compression).
>
> One problem is that AOLserver doesn't gzip content when ns_return is
> called; it works for pretty much every scenario except that one.  I don't
> know why this is the case; we just hacked this by recompiling nsd to always
> gzip regardless of the config file, as long as the client supports it (line
> 161 of connio.c).  It would be nice if this worked correctly by default (or
> if we figured out the proper way to enable its use in ns_return).
>
>
> On Wed, Dec 1, 2010 at 9:46 PM, Tom Jackson  wrote:
>
>> All you are doing here is using ns_zlib in Tcl. Who cares if this
>> works or not? It is possible that HTTP content compression is slightly
>> different than what is produced by ns_zlib. But this doesn't matter
>> really. What you should be testing is ns_returnz (sp?) or ns_return
>> (or adp output) with transparent compression (which takes into account
>> client capabilities, you can't just blindly send compressed content).
>>
>> I remember looking into ns_zlib just because it was part of the adp
>> processing/fastpath code. I don't have any reason to believe that, if
>> configured correctly it doesn't work. I also doubt that ns_zlib would
>> have wound up in the core unless it worked, the author is well known
>> and I've never heard of anyone suggesting any of the repo modules
>> "don't work".
>>
>> I'll try to look into how ns_zlib is supposed to work. Maybe this is a
>> total lack of documentation problem.
>>
>> tom jackson
>>
>> On Wed, Dec 1, 2010 at 10:19 AM, Alexey Pechnikov
>>  wrote:
>> > This work correct:
>> > ns_register_proc GET /test  ad_test_proc
>> > proc ad_test_proc {ignore} {
>> > set gzip [ns_zlib gzip "test"]
>> > set time [ns_httptime [ns_time]]
>> > ns_write "HTTP/1.0 200 OK
>> > Content-Type: text/plain; charset=utf-8
>> > Content-Encoding: gzip
>> > \n"
>> > ns_write $gzip
>> > }
>> > $ curl http://localhost:8200/test 2>/dev/null| hexdump
>> > 000 8b1f 0008   0300 492b 2e2d 0001
>> > 010 7e0c d87f 0004 
>> > 018
>> >
>> > But is possible to disable all output translations by ns_return? Where
>> is
>> > documented how ns_return process the data?..
>> > --
>> > Best regards, Alexey Pechnikov.
>> > http://pechnikov.tel/
>> >
>> > --
>> > AOLserver - http://www.aolserver.com/
>> >
>> > To Remove yourself from this list, simply send an email to
>> >  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 <
>> lists...@listserv.aol.com> with the
>> body of "SIGNOFF AOLSERVER" in the email message. You c

Re: [AOLSERVER] TLS package issue

2010-12-06 Thread Jeff Hobbs

On 06/12/2010 3:14 AM, aT wrote:

We are using the TLS package to call a certain HTTPs API, we do usually
import the package using "package require" command then doing a normal
"::http::register https 443 ::tls::socket"

Sometimes a strange error just appear saying that "invalid ::tls:socket
command".


Is this a copy & paste direct?  If so, tls::socket has 2 :s, the above 
shows only one, so it would be a correct complaint.  Otherwise just make 
sure there is a reference to 'package require tls' before tls is used.



Am assuming that the issue is happening due to a failure while importing
the TLS package and its random.. may be this is happening because the
package is already imported and am trying to import it again? or because
of an open sockets somewhere that should be closed? is it a bug in AOL?

We are using Aolserver 4.0.10 . TLS version is 1.6 Its a 64bit linux
environment ,

Has any one encountered same using TLS .


BTW, everyone should be using 1.6.1 because it fixed a mem leak on each 
tls::status call.


Jeff


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

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


Re: [AOLSERVER] TLS package issue

2010-12-06 Thread Michael A. Cleverly
On Mon, Dec 6, 2010 at 10:18 AM, Jeff Hobbs  wrote:

> BTW, everyone should be using 1.6.1 because it fixed a mem leak on each
> tls::status call.

I only see "1.6" at http://sourceforge.net/projects/tls/files/tls/
(released on 2008-03-24).  Where is the best place to grab 1.6.1?

Michael


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

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


Re: [AOLSERVER] TLS package issue

2010-12-06 Thread Jeff Hobbs

On 06/12/2010 1:14 PM, Michael A. Cleverly wrote:

On Mon, Dec 6, 2010 at 10:18 AM, Jeff Hobbs  wrote:


BTW, everyone should be using 1.6.1 because it fixed a mem leak on each
tls::status call.


I only see "1.6" at http://sourceforge.net/projects/tls/files/tls/
(released on 2008-03-24).  Where is the best place to grab 1.6.1?


Ah, lazy me.  It's tagged in cvs but has never had the dist placed on SF 
Files.


Jeff


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

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


Re: [AOLSERVER] Does not work ns_return + zlib

2010-12-06 Thread Tom Jackson
On Mon, Dec 6, 2010 at 9:13 AM, Alexey Pechnikov  wrote:
> I'm see the code in connio.c:
>     /*
>      * GZIP the content when not streaming if enabled and the content
>      * length is above the minimum.
>      */
>     if (!stream
>    && (conn->flags & NS_CONN_GZIP)
>    && (servPtr->opts.flags & SERV_GZIP)
>    && (len > (int) servPtr->opts.gzipmin)
>    && (ahdr = Ns_SetIGet(conn->headers, "Accept-Encoding")) != NULL
>    && strstr(ahdr, "gzip") != NULL
>    && Ns_Gzip(buf, len, servPtr->opts.gziplevel, &gzip) == NS_OK) {
> buf = gzip.string;
> len = gzip.length;
> Ns_ConnCondSetHeaders(conn, "Content-Encoding", "gzip");
>     }
> There are no checks for content-type and older version of Internet Explorer
> (IE5, IE6 and may be IE7 have a lot of problems with gzipped scripts and
> styles).

And yet your examples provided even less customization. There is
almost no reason to waste cpu on compressing output, just provide a
gzipped file for very large files. Who are you trying to save money
for anyway?

> I don't think that this code is useful for production.

Right, then don't use it.

> And we may
> add ETAG functionality and smart caching checksums of results for decreasing
> data transfer and server loading. I dont know about your situation but my
> clients have limited internet connections (especially on mobile devices) and
> ETAG header transmitting is faster when gzipped content...

Then the least of your problems is gzipping content, you need to
actively minimize the data transfered. But all of this sounds like
_your_ problem, not the problem of a generic application server. You
haven't even figured out how automatic compression works in AOLserver
yet you want to propose additional features.

> For static files
> on group of hosts application-defined ETAG is helpful too but internal AOL
> last-modified-since mechanizm is niot useful (it's not the AOL problem, of
> cource).

??

> P.S. I dont understand why my suggestion to complete AOL documentation by
> examples was produce the holywar about Tcl 8.4 vs 8.5 vs 8.6.

Because I'm a jerk and overreact to what I think are idiotic statements?

BTW, you didn't provide any useful additions to AOLserver documentation.

> I think AOL
> 4.5.1 + Tcl 8.5 is better choice for new projects and Tcl 8.6 is better for
> some utilities (fast internal base64 realization, half-closed sockets and
> other features help me to build faster applications with a few lines of
> code).

I agree with Gustaf: the latest 8.5 is worth the effort. There are
certain features which simplify very annoying code. This is true even
if your version of 8.5 is slower than 8.4. But you have to actively
update your code to take advantage of the new features. The more code
you have, the less benefit you get from upgrading without code
conversion. However, Gustaf mentioned a higher stability in 8.5. This
could easily override the limited benefit of simply moving the Tcl
library to 8.5 from 8.4.

> Tcl 8.6 documentation of zlib functions is much better than AOL
> documentation of ns_zlib module and some of this docs and examples can be
> helpful for AOL, why not?

If you use Tcl, use the Tcl documentation. If you use AOLserver, use
the AOLserver documentation. I'm not sure why you keep confusing these
two things.

tom jackson (AKA the jerk)


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

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


Re: [AOLSERVER] Does not work ns_return + zlib

2010-12-06 Thread Jeff Rogers

Hossein Sharifi wrote:
One problem is that AOLserver doesn't gzip content when ns_return is 
called; it works for pretty much every scenario except that one.  I 
don't know why this is the case; we just hacked this by recompiling nsd 
to always gzip regardless of the config file, as long as the client 
supports it (line 161 of connio.c).  It would be nice if this worked 
correctly by default (or if we figured out the proper way to enable its 
use in ns_return).


I only skimmed over the code, but it looks like the problem is that the 
content is only gzipped if the NS_CONN_GZIP flag is set on the conn, and 
the only place that flag is set is in the adp processor.


The obvious (I think) improvement is to expose 
Ns_ConnGetGzipFlag/Ns_ConnSetGzipFlag as subcommands of ns_conn, which 
would let you write a filter to do the ancient/broken browser checking 
or whatever else you needed and turn gzip on or off as needed. 
(However, doing this could impact adp processing, so a corresponding 
change might need to be made there, lest your adp code has a different 
idea about what should or shouldn't be compressed)


-J


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

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


Re: [AOLSERVER] Does not work ns_return + zlib

2010-12-06 Thread Brett Schwarz
> - Original Message 
> From: Jeff Rogers 
> To: AOLSERVER@LISTSERV.AOL.COM
> Sent: Mon, December 6, 2010 3:40:47 PM
> Subject: Re: [AOLSERVER] Does not work ns_return + zlib
>
> Hossein Sharifi wrote:
> > One problem is that AOLserver doesn't gzip content when ns_return is 
> > called; 
>it works for pretty much 
>
> every scenario except that one.  I don't know why this is the case; we just 
>hacked this by recompiling 
>
> nsd to always gzip regardless of the config file, as long as the client 
>supports it (line 161 of connio.c).  It 
>
> would be nice if this worked correctly by default (or if we figured out the 
>proper way to enable its use in 
>
> ns_return).
>
> I only skimmed over the code, but it looks like the problem is that the 
> content 
>is only gzipped if the NS_CONN_GZIP flag is set on the conn, and the only 
>place 
>that flag is set is in the adp processor.
>
> The obvious (I think) improvement is to expose 
>Ns_ConnGetGzipFlag/Ns_ConnSetGzipFlag as 
>
> subcommands of ns_conn, which would let you write a filter to do the 
>ancient/broken browser checking 
>
> or whatever else you needed and turn gzip on or off as needed. (However, 
> doing 
>this could impact adp 
>
> processing, so a corresponding change might need to be made there, lest your 
>adp code has a different 
>
> idea about what should or shouldn't be compressed)

We had a similar discussion about this a couple years ago. See 
http://www.mail-archive.com/aolserver@listserv.aol.com/msg11598.html (although 
the threading is messed up in the mail archive, so you will have to skip 
around).


At the time, if I remember, there wasn't a real consensus, so I made changes in 
my sandbox to mimic the adp compression but for ns_return. If people are 
interested, I can try to dig up the code.


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

To Remove yourself from this list, simply send an email to 
 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 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.