|
From: SourceForge.net <no...@so...> - 2006-06-22 14:36:39
|
Bugs item #1510702, was opened at 2006-06-22 07:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1510702&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 24. Channel Commands Group: current: 8.4.13 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: 8.4.13 on win2k: eof problem on socket channels Initial Comment: I met with the problem when it took cca. 20 secs for ::http::geturl to return form an url fetch that was instantenous in Mozilla Firefox. I then tried my old code I had written for the same purpose: ################################################################## proc rdhdrs {chan} { global headers #Separate the headers from the body if {[set n [gets $chan s]] != 0} { if {$n < 0} {return} append headers $s\n } else { fconfigure $chan -translation binary -encoding binary fileevent $chan readable [list rdcont $chan] } } proc rdcont {chan} { global FL body set frag [read $chan] if {![eof $chan]} { append body $frag } else { fileevent $chan readable {} set FL 1 } } proc geturl {host resrc cki} { global FL body rqhdrs headers set headers "" set ch [socket $host 80] fconfigure $ch -translation {auto crlf} -blocking 0 -buffersize 8192 # fconfigure $ch -translation {auto crlf} -blocking 0 -buffering line -buffersize 8192 fileevent $ch readable [list rdhdrs $ch] puts $ch "GET $resrc HTTP/1.1" puts $ch "Host: $host" puts $ch $rqhdrs if {$cki ne ""} {puts $ch $cki} puts $ch "" flush $ch vwait FL close $ch } ################################################################## As it turns out the read command that should detect the eof condition after the message body has been read in does not returns immediaely but only after the above long delay that seems to be a time-out. The result is the same if "-blocking 1" is set on the channel. I also noticed another newly occuring problem. The original version worked with "-buffering line" and without the flush command. Http sniffing revealed that in this case now only the first line was sent. I have recently changed to 8.4.13 from either 8.4.9 or 8.4.11 (I can remember which) and until now I have not faced this problem although I use WEB scraping quite frequently for complex search sequences. Joe Nemeth joe...@cp... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1510702&group_id=10894 |