[Tcl-bugs] [ tcl-Bugs-1510702 ] 8.4.13 on win2k: eof problem on socket channels

[SourceForge.net <no...@so...>]

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