Problems reading from a specific web site
in [TCL]
|
Prev: passing "arrays of structs" in procs.
Next: Question about common practices on building applications on Tk (or "OO + Tk")
From: Alan Grunwald on 5 Mar 2010 11:08 Hi all, I'm trying to get some data via http. set tok [http::geturl $myUrl] puts stdout [http::code $tok] displays nothing. (I'm using http version 2.7.2 from the Active State teapot, and ActiveTcl 8.6b1.1 on Ubuntu.) I've done some digging and the problem seems to be towards the top of Event, where the following code may be found: if {$state(state) eq "connecting"} { set state(state) "header" if {[catch {gets $sock state(http)} n]} { return [Finish $token $n] } } elseif... It appears that the [gets] in this code snippet returns -1, because of this, when the code gets to the point where it reads the blank line marking the end of the headers, state(http) is zero length; the code seems to assume that this means it has received an HTTP/1.1 100 Continue response, and doesn't set its state to body. I'm not sure exactly what happens afterwards, but this is obviously a Bad Thing. I tried changing the code snippet above to if {$state(state) eq "connecting"} { if {[catch {gets $sock state(http)} n]} { return [Finish $token $n] } if {$n > -1} { set state(state) "header" } } elseif... and it works fine for the url I'm interested in, and also for the one other url I tested it on. Please can someone who knows more than me about the http protocol and [gets] (this shouldn't exclude too many people :-)) re-assure me that the code change is legitimate. Can anyone suggest what may be going wrong on the server side? The headers I'm reading from the "odd" site include "Server Microsoft-IIS/6.0 X-Powered-By PHP/5.2.4 X-Powered-By ASP.NET", which rather prejudices me against it. It's the first version of a new server, so there might be problems at the server side, I'm sure they'd appreciate any hints or pointers I can provide. Many thanks, -- Alan
From: Alexandre Ferrieux on 5 Mar 2010 12:06 On Mar 5, 5:08 pm, Alan Grunwald <alan-clt-pos...(a)nospam.demon.co.uk> wrote: > Hi all, > > I'm trying to get some data via http. > > set tok [http::geturl $myUrl] > puts stdout [http::code $tok] > > displays nothing. (I'm using http version 2.7.2 from the Active State > teapot, and ActiveTcl 8.6b1.1 on Ubuntu.) > > I've done some digging and the problem seems to be towards the top > of Event, where the following code may be found: > > if {$state(state) eq "connecting"} { > set state(state) "header" > if {[catch {gets $sock state(http)} n]} { > return [Finish $token $n] > } > } elseif... > > It appears that the [gets] in this code snippet returns -1, because of > this, when the code gets to the point where it reads the blank line > marking the end of the headers, state(http) is zero length; the code > seems to assume that this means it has received an HTTP/1.1 100 Continue > response, and doesn't set its state to body. I'm not sure exactly what > happens afterwards, but this is obviously a Bad Thing. > > I tried changing the code snippet above to > > if {$state(state) eq "connecting"} { > if {[catch {gets $sock state(http)} n]} { > return [Finish $token $n] > } > if {$n > -1} { > set state(state) "header" > } > } elseif... > > and it works fine for the url I'm interested in, and also for the one > other url I tested it on. > > Please can someone who knows more than me about the http protocol and > [gets] (this shouldn't exclude too many people :-)) re-assure me that > the code change is legitimate. > > Can anyone suggest what may be going wrong on the server side? The > headers I'm reading from the "odd" site include "Server > Microsoft-IIS/6.0 X-Powered-By PHP/5.2.4 X-Powered-By ASP.NET", which > rather prejudices me against it. It's the first version of a new server, > so there might be problems at the server side, I'm sure they'd > appreciate any hints or pointers I can provide. > > Many thanks, > > -- > Alan Regardless of whether the server is behaving slightly or grossly wrong, or not wrong at all, it looks like a bug in our http package. In order to collect analysis, traces, and proposed patches in a rational fashion, could you please post a bugreport ? TIA, -Alex
From: Alan Grunwald on 5 Mar 2010 13:19 Alexandre Ferrieux wrote: > On Mar 5, 5:08 pm, Alan Grunwald <alan-clt-pos...(a)nospam.demon.co.uk> > wrote: >> Hi all, >> >> I'm trying to get some data via http. >> >> set tok [http::geturl $myUrl] >> puts stdout [http::code $tok] >> >> displays nothing. (I'm using http version 2.7.2 from the Active State >> teapot, and ActiveTcl 8.6b1.1 on Ubuntu.) >> >> I've done some digging and the problem seems to be towards the top >> of Event, where the following code may be found: >> >> if {$state(state) eq "connecting"} { >> set state(state) "header" >> if {[catch {gets $sock state(http)} n]} { >> return [Finish $token $n] >> } >> } elseif... >> >> It appears that the [gets] in this code snippet returns -1, because of >> this, when the code gets to the point where it reads the blank line >> marking the end of the headers, state(http) is zero length; the code >> seems to assume that this means it has received an HTTP/1.1 100 Continue >> response, and doesn't set its state to body. I'm not sure exactly what >> happens afterwards, but this is obviously a Bad Thing. >> >> I tried changing the code snippet above to >> >> if {$state(state) eq "connecting"} { >> if {[catch {gets $sock state(http)} n]} { >> return [Finish $token $n] >> } >> if {$n > -1} { >> set state(state) "header" >> } >> } elseif... >> >> and it works fine for the url I'm interested in, and also for the one >> other url I tested it on. >> >> Please can someone who knows more than me about the http protocol and >> [gets] (this shouldn't exclude too many people :-)) re-assure me that >> the code change is legitimate. >> >> Can anyone suggest what may be going wrong on the server side? The >> headers I'm reading from the "odd" site include "Server >> Microsoft-IIS/6.0 X-Powered-By PHP/5.2.4 X-Powered-By ASP.NET", which >> rather prejudices me against it. It's the first version of a new server, >> so there might be problems at the server side, I'm sure they'd >> appreciate any hints or pointers I can provide. >> >> Many thanks, >> >> -- >> Alan > > Regardless of whether the server is behaving slightly or grossly > wrong, or not wrong at all, it looks like a bug in our http package. > In order to collect analysis, traces, and proposed patches in a > rational fashion, could you please post a bugreport ? > > TIA, > > -Alex Is that the main tcl bug tracker on sourceforge?
From: Alexandre Ferrieux on 5 Mar 2010 14:01 On Mar 5, 7:19 pm, Alan Grunwald <alan-clt-pos...(a)nospam.demon.co.uk> wrote: > Alexandre Ferrieux wrote: > > On Mar 5, 5:08 pm, Alan Grunwald <alan-clt-pos...(a)nospam.demon.co.uk> > > wrote: > >> Hi all, > > >> I'm trying to get some data via http. > > >> set tok [http::geturl $myUrl] > >> puts stdout [http::code $tok] > > >> displays nothing. (I'm using http version 2.7.2 from the Active State > >> teapot, and ActiveTcl 8.6b1.1 on Ubuntu.) > > >> I've done some digging and the problem seems to be towards the top > >> of Event, where the following code may be found: > > >> if {$state(state) eq "connecting"} { > >> set state(state) "header" > >> if {[catch {gets $sock state(http)} n]} { > >> return [Finish $token $n] > >> } > >> } elseif... > > >> It appears that the [gets] in this code snippet returns -1, because of > >> this, when the code gets to the point where it reads the blank line > >> marking the end of the headers, state(http) is zero length; the code > >> seems to assume that this means it has received an HTTP/1.1 100 Continue > >> response, and doesn't set its state to body. I'm not sure exactly what > >> happens afterwards, but this is obviously a Bad Thing. > > >> I tried changing the code snippet above to > > >> if {$state(state) eq "connecting"} { > >> if {[catch {gets $sock state(http)} n]} { > >> return [Finish $token $n] > >> } > >> if {$n > -1} { > >> set state(state) "header" > >> } > >> } elseif... > > >> and it works fine for the url I'm interested in, and also for the one > >> other url I tested it on. > > >> Please can someone who knows more than me about the http protocol and > >> [gets] (this shouldn't exclude too many people :-)) re-assure me that > >> the code change is legitimate. > > >> Can anyone suggest what may be going wrong on the server side? The > >> headers I'm reading from the "odd" site include "Server > >> Microsoft-IIS/6.0 X-Powered-By PHP/5.2.4 X-Powered-By ASP.NET", which > >> rather prejudices me against it. It's the first version of a new server, > >> so there might be problems at the server side, I'm sure they'd > >> appreciate any hints or pointers I can provide. > > >> Many thanks, > > >> -- > >> Alan > > > Regardless of whether the server is behaving slightly or grossly > > wrong, or not wrong at all, it looks like a bug in our http package. > > In order to collect analysis, traces, and proposed patches in a > > rational fashion, could you please post a bugreport ? > > > TIA, > > > -Alex > > Is that the main tcl bug tracker on sourceforge? Yes, since that's in the pure-Tcl http package in the 'library' subdirectory of the Tcl source tree. -Alex
From: Alan Grunwald on 5 Mar 2010 16:50
Alexandre Ferrieux wrote: > On Mar 5, 7:19 pm, Alan Grunwald <alan-clt-pos...(a)nospam.demon.co.uk> > wrote: >> Alexandre Ferrieux wrote: >>> On Mar 5, 5:08 pm, Alan Grunwald <alan-clt-pos...(a)nospam.demon.co.uk> >>> wrote: >>>> Hi all, >>>> I'm trying to get some data via http. >>>> set tok [http::geturl $myUrl] >>>> puts stdout [http::code $tok] >>>> displays nothing. (I'm using http version 2.7.2 from the Active State >>>> teapot, and ActiveTcl 8.6b1.1 on Ubuntu.) >>>> I've done some digging and the problem seems to be towards the top >>>> of Event, where the following code may be found: >>>> if {$state(state) eq "connecting"} { >>>> set state(state) "header" >>>> if {[catch {gets $sock state(http)} n]} { >>>> return [Finish $token $n] >>>> } >>>> } elseif... >>>> It appears that the [gets] in this code snippet returns -1, because of >>>> this, when the code gets to the point where it reads the blank line >>>> marking the end of the headers, state(http) is zero length; the code >>>> seems to assume that this means it has received an HTTP/1.1 100 Continue >>>> response, and doesn't set its state to body. I'm not sure exactly what >>>> happens afterwards, but this is obviously a Bad Thing. >>>> I tried changing the code snippet above to >>>> if {$state(state) eq "connecting"} { >>>> if {[catch {gets $sock state(http)} n]} { >>>> return [Finish $token $n] >>>> } >>>> if {$n > -1} { >>>> set state(state) "header" >>>> } >>>> } elseif... >>>> and it works fine for the url I'm interested in, and also for the one >>>> other url I tested it on. >>>> Please can someone who knows more than me about the http protocol and >>>> [gets] (this shouldn't exclude too many people :-)) re-assure me that >>>> the code change is legitimate. >>>> Can anyone suggest what may be going wrong on the server side? The >>>> headers I'm reading from the "odd" site include "Server >>>> Microsoft-IIS/6.0 X-Powered-By PHP/5.2.4 X-Powered-By ASP.NET", which >>>> rather prejudices me against it. It's the first version of a new server, >>>> so there might be problems at the server side, I'm sure they'd >>>> appreciate any hints or pointers I can provide. >>>> Many thanks, >>>> -- >>>> Alan >>> Regardless of whether the server is behaving slightly or grossly >>> wrong, or not wrong at all, it looks like a bug in our http package. >>> In order to collect analysis, traces, and proposed patches in a >>> rational fashion, could you please post a bugreport ? >>> TIA, >>> -Alex >> Is that the main tcl bug tracker on sourceforge? > > Yes, since that's in the pure-Tcl http package in the 'library' > subdirectory of the Tcl source tree. > > -Alex Done. New tracker ID 2964525 -- Alan |