Need HTTP 1.1 support in TCL
Bud
1.0. Since TCL is the de-facto scripting language in the networking
industry we, or at least me, need to be able to develop TCL test and
automation scripts for testing both HTTP 1.0 and HTTP 1.1.
Are there any plans for upgrading the library package to include 1.1? If
not is there a 3rd party add-in with 1.1 support?
Thanks.
bud
Mats Bengtsson
I've just started to add at least support for persistent connections,
default and required mode in 1.1, which I need in my whiteboard to get through
firewalls using http proxies. "http://hem.fyristorg.com/matben/"
Also added a PUT operation. Not well tested yet. Any other attempts to do this?
Perhaps a joint effort...
Another thing: how common are http 1.1 proxies compared to 1.0?
Mats
Michael Schlenker
http://personal1.iddeo.es/andresgarci/tclcurl/english/
Michael Schlenker
Jeff Hobbs
...
> Are there any plans for upgrading the library package to include 1.1? If
> not is there a 3rd party add-in with 1.1 support?
I believe Pat Thoyts and/or Dan Kuchler posted a patch that added
some 1.1 features to http on the newsgroup. You'd have to do a
google groups search for it though.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
http://www.ActiveState.com/Products/ASPN_Tcl/
Cameron Laird
Jeff Hobbs <Je...@ActiveState.com> wrote:
>Bud wrote:
> ...
>> Are there any plans for upgrading the library package to include 1.1? If
>> not is there a 3rd party add-in with 1.1 support?
>
>I believe Pat Thoyts and/or Dan Kuchler posted a patch that added
>some 1.1 features to http on the newsgroup. You'd have to do a
>google groups search for it though.
.
.
<URL: http://groups.google.com/groups?th=d5caca40bac5a72f >
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Pat Thoyts
There was some discussion about this a while ago which you can read at
http://tclsoap.sourceforge.net/http.tcl which resulted in a modified
version of the current http package supporting keepalive connections
and some 1.1 requirements. I have some other bits from other
people. This might do the job, or you could look into TclCurl which
definately does what you want.
--
Pat Thoyts http://www.zsplat.freeserve.co.uk/resume.html
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
Your name
news:a3277m$q59$1...@slb3.atl.mindspring.net:
> Are there any plans for upgrading the library package to include 1.1?
> If not is there a 3rd party add-in with 1.1 support?
Mmmmm I think we first need to fix the http package not to hang when
resolving nonexistent/down servers... thats a biggie for me to just exec
something else, like curl (http://curl.haxx.se) thanks Daniel S., you rock!
jooky
lvi...@yahoo.com
According to Pat Thoyts <Cng.G...@ovtsbbg.pbz>:
:There was some discussion about this a while ago which you can read at
:http://tclsoap.sourceforge.net/http.tcl which resulted in a modified
:version of the current http package supporting keepalive connections
:and some 1.1 requirements. I have some other bits from other
:people.
Are there plans to get this checked into Tcl before Tcl 8.4.0 is released?
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Phil Dietz
http://tclsoap.sourceforge.net/http.html
Eric Boudallier wrote one that he's emailed a few people.
- It uses a proprietary package called url:: and changes the semantics
of http::geturl (the url must first be registered with http::request
before calling http::geturl).
Pat Thoyts
>According to Pat Thoyts <Cng.G...@ovtsbbg.pbz>:
>:There was some discussion about this a while ago which you can read at
>:http://tclsoap.sourceforge.net/http.tcl which resulted in a modified
>:version of the current http package supporting keepalive connections
>:and some 1.1 requirements. I have some other bits from other
>:people.
>
>
>Are there plans to get this checked into Tcl before Tcl 8.4.0 is released?
In a word - No.
In more words - I don't actually know when 8.4 is due for
release. However, I'd prefer to make the http mods properly 1.1
compliant before submission. At the moment it only really does
keepalive. I assume it also needs to go through TIPing too. Plus there
seem to be some cases where it fails (-command for one.)
I have some comments and a sample package to go on with that I should
upload for perusal and I need to find some time to do more work on
this.
incr http(priority)
Pat Thoyts
I have Eric's code. I plan to merge his idea and mine and see if we
can't get something useful. When I get the chance I might see if
TclCurl can be used in place when available too. In the meantime -
TclCurl is ready to be used. It is still worth having a Tcl-only
implementation in my opinion though.
Personally I'm not so keen on changing the calling semantics of
geturl.
Don Porter
>
>>According to Pat Thoyts <Cng.G...@ovtsbbg.pbz>:
>>:There was some discussion about this a while ago which you can read at
>>:http://tclsoap.sourceforge.net/http.tcl which resulted in a modified
>>:version of the current http package supporting keepalive connections
>>:and some 1.1 requirements. I have some other bits from other
>>:people.
>>
>>
>>Are there plans to get this checked into Tcl before Tcl 8.4.0 is released?
>
> In a word - No.
[ Adding HTTP 1.1 support to the http package]
Pat Thoyts wrote:
> In more words - I don't actually know when 8.4 is due for
> release. However, I'd prefer to make the http mods properly 1.1
> compliant before submission. At the moment it only really does
> keepalive. I assume it also needs to go through TIPing too.
Just MHO:
If you're going to submit a TIP for the http package, just submit
this one:
TIP: Move http package to tcllib
Just take it out of TCT hands and put it in tcllib where interested
folks can run with it without TIP overhead on every separate point.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Jeff Hobbs
> [ Adding HTTP 1.1 support to the http package]
> If you're going to submit a TIP for the http package, just submit
> this one:
>
> TIP: Move http package to tcllib
>
> Just take it out of TCT hands and put it in tcllib where interested
> folks can run with it without TIP overhead on every separate point.
While TIP overhead is not nice, on this point I would strongly
argue that http cannot be moved wholesale into tcllib. As a
core function of Tcl it really does provide value, being a core
building block for getting other functionality. I would agree
that HTTP/1.1 compatability and an http v3 package could be
added to tcllib. This means that http v2 will always be around,
and http on steroids can be in tcllib, where it is more appropriate.
Don Porter
> I would agree
> that HTTP/1.1 compatability and an http v3 package could be
> added to tcllib. This means that http v2 will always be around,
> and http on steroids can be in tcllib, where it is more appropriate.
That's the perfect answer. Thanks!
http 3, go forth and prosper!
Pat Thoyts
>In article <3C5730C4...@ActiveState.com>, Jeff Hobbs wrote:
>> I would agree
>> that HTTP/1.1 compatability and an http v3 package could be
>> added to tcllib. This means that http v2 will always be around,
>> and http on steroids can be in tcllib, where it is more appropriate.
>
>That's the perfect answer. Thanks!
>
>http 3, go forth and prosper!
>
Seems like a pretty good plan. Once it's shown to be stable the TCT
can choose to upgrade the core package or not as they deem fit.
Still got to do the work though!
lvi...@yahoo.com
According to Mats Bengtsson <mats.be...@foi.se>:
:I've just started to add at least support for persistent connections,
:default and required mode in 1.1, which I need in my whiteboard to get through
:firewalls using http proxies. "http://hem.fyristorg.com/matben/"
:Also added a PUT operation. Not well tested yet. Any other attempts to do this?
:Perhaps a joint effort...
I hope that you also talk to Pat Thoyts, who is also working on the same
thing.
I think it would be worthwhile for all you kind people to drop a note
to Jeff Hobbs as well, as he is the maintenance person for the package -
perhaps there is a mini-mailing list, etc. that would be appropriate.
Phil Dietz
> While TIP overhead is not nice, on this point I would strongly
> argue that http cannot be moved wholesale into tcllib. As a
> core function of Tcl it really does provide value, being a core
> building block for getting other functionality. I would agree
> that HTTP/1.1 compatability and an http v3 package could be
> added to tcllib. This means that http v2 will always be around,
> and http on steroids can be in tcllib, where it is more appropriate.
Seems to me this would allow the HTTP::mapReply v3 procedure to be
replaced with a much faster C version.
When I replaced the function, I got a huge improvement.
Here's the time to encode http.tcl (11k file) using tcl8.0:
http::mapReply 2.61 secs
httpMapReply 1.63 secs
C::urlEncode 0.04 secs
Here's using tcl8.4a3:
http::mapReply 4.39 secs
httpMapReply 5.20 secs
C::urlEncode 0.05 secs
lvi...@yahoo.com
According to Jeff Hobbs <Je...@ActiveState.com>:
: on this point I would strongly
:argue that http cannot be moved wholesale into tcllib. As a
:core function of Tcl it really does provide value,
I am unable to understand how the purely tcl script http package is core
functionality but similar code for things like ftp, telnet, etc. are considered
to be satisfactory to go into tcllib.
Are there parts of the Tcl build infrastructure which currently require http?
Jeffrey Hobbs
>
> According to Jeff Hobbs <Je...@ActiveState.com>:
> : on this point I would strongly
> :argue that http cannot be moved wholesale into tcllib. As a
> :core function of Tcl it really does provide value,
>
> I am unable to understand how the purely tcl script http package is core
> functionality but similar code for things like ftp, telnet, etc. are considered
> to be satisfactory to go into tcllib.
>
> Are there parts of the Tcl build infrastructure which currently require http?
No, but there are very good plans for a build/installation
infrastructure that extends itself that does require http.
Also, the meer fact that it is now in the core prevents
moving it until something like 9.0 anyway.
David Bleicher
> lvi...@yahoo.com wrote:
> >
> > According to Jeff Hobbs <Je...@ActiveState.com>:
> > : on this point I would strongly
> > :argue that http cannot be moved wholesale into tcllib. As a
> > :core function of Tcl it really does provide value,
> >
> > I am unable to understand how the purely tcl script http package is core
> > functionality but similar code for things like ftp, telnet, etc. are considered
> > to be satisfactory to go into tcllib.
> >
> > Are there parts of the Tcl build infrastructure which currently require http?
>
> No, but there are very good plans for a build/installation
> infrastructure that extends itself that does require http.
> Also, the meer fact that it is now in the core prevents
> moving it until something like 9.0 anyway.
Curious :} I'm just thinking that any "build/installation
infrastructure" that relies on HTTP would be likely (IMHO) to make a
number of sequential HTTP requests to the same server (retrieving
files for installation?). I'd further speculate that such a system
would perform much faster if it had access to HTTP/1.1 socket
keep-alive functionality.
Jeff, I'll go ahead and ask: Are we thinking about TPM (TCL Package
Manager)? If so, wouldn't the speed improvement (and server load
reduction) of socket reuse be a critical to such an application? Am I
just wildly overestimating it's value?
David
---
--
-
Darren New
> I'd further speculate that such a system
> would perform much faster if it had access to HTTP/1.1 socket
> keep-alive functionality.
Id' further speculate this would make much more sense using FTP. :-)
Especially since there's presumedly no hypertext involved.
It's always amusing to watch HTTP try to evolve into FTP ;-)
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
The opposite of always is sometimes.
The opposite of never is sometimes.
Jeffrey Hobbs
>
> David Bleicher wrote:
> > I'd further speculate that such a system
> > would perform much faster if it had access to HTTP/1.1 socket
> > keep-alive functionality.
>
> Id' further speculate this would make much more sense using FTP. :-)
> Especially since there's presumedly no hypertext involved.
>
> It's always amusing to watch HTTP try to evolve into FTP ;-)
Yes, I was implying a Tcl Package Manager application. Also, I
think HTTP is more applicable than FTP in this case, as it is much
more directed (no login required). Think of HTTP as the
point-and-shoot while FTP is SLR, and we just want simple snaps.
HTTP/1.1 might improve performance there, but that would only be
if you are extremely loading the server with HTTP/1.0 already.
Michael Schlenker
> Darren New wrote:
>
>>David Bleicher wrote:
>>
>>>I'd further speculate that such a system
>>>would perform much faster if it had access to HTTP/1.1 socket
>>>keep-alive functionality.
>>>
>>Id' further speculate this would make much more sense using FTP. :-)
>>Especially since there's presumedly no hypertext involved.
>>
>>It's always amusing to watch HTTP try to evolve into FTP ;-)
>>
>
> Yes, I was implying a Tcl Package Manager application. Also, I
> think HTTP is more applicable than FTP in this case, as it is much
> more directed (no login required). Think of HTTP as the
> point-and-shoot while FTP is SLR, and we just want simple snaps.
(passive mode is ok.)
Are there thoughts to expand the [package require] cmd? With the vfs
extension it should be easy to do a package require from a web server.
Any ideas in that direction?
Michael Schlenker
pe...@browsex.com
> jooky
I also modified http.tcl to support keepalives, and it's been
used for about a year or so in BrowseX. However, it's much more
complex a patch (800 vs 300 lines) as it implements and manages
a queue internally. Mainly, the problem I saw is that many web sites
seem to only allow a pipeline of about 6 or 7 outstanding requests.
And there are, certain web servers (eg Netscape-Enterprise/3 and WebLogic)
that pipelining doesn't seem to work it all and had to be disabled on.
Anyways, I can't make any claims to usability, nor in fact,
that it works 100% of the time.
I mention it mostly because it also implements a -address geturl option
to support a DNS cache to speed things up and prevent resolver hangs.
If your interested in a look:
http://dev.browsex.com/http.tcl
--
Peter MacDonald BrowseX Systems Inc
Email: pe...@BrowseX.com http://BrowseX.com
Phone: (250) 595-5998