Tclhttpd: unable to serve .swf files?
in [TCL]
|
From: tom.rmadilo on 18 Jun 2010 11:09 On Jun 18, 2:22 am, Giorgio Valoti <giorgi...(a)me.com> wrote: > On 2010-06-17 17:58:49 +0200, Giorgio Valoti said: > > > > > > > On 2010-06-17 17:36:11 +0200, tom.rmadilo said: > > >> [ ] > > >> Until you use something like telnet, or Tcl's socket to try a raw > >> request, and show us what you typed and the full result, it is hard to > >> help much further. From what I understand, it isn't hanging, it is > >> just returning some headers. Telnet will maybe show some data getting > >> sent. > > > With curl I dont see any response header: > > > C:\Documents and Settings\admin\Desktop\curl-7.19.5>curl -v > >http://localhost:801 > > 5/images/Space.gif > > * About to connect() to localhost port 8015 (#0) > > * Trying 127.0.0.1... connected > > * Connected to localhost (127.0.0.1) port 8015 (#0) > >> GET /images/Space.gif HTTP/1.1 > >> User-Agent: curl/7.19.5 (i586-pc-mingw32msvc) libcurl/7.19.5 zlib/1.2.3 > >> Host: localhost:8015 > >> Accept: */* > > I have reduced the problem to line (proc Httpd_ReturnFile on httpd.tcl): > > fcopy $in $sock -command [list HttpdCopyDone $in $sock $close] > > which copies the contents of the file to the socket. For some reasons > it blocks when some particular files are requested on Windows XP and > tclhttpd serves the file from a starkit. Is it possible the response code makes another request back to the same server? I have an application which runs under regular tcl [socket], but hangs under tclhttpd. I gave up looking for the reason, but months later considered that I messed up my fcopy command. What I would look for is an [fcopy] which doesn't go into the background with a -command option and doesn't place a file into nonblocking mode. It is also possible that some code, for some reason puts one of the channels back into blocking mode, or tries to work with either the $in or $sock channels. Maybe there is some way to monitor channel configuration changes during a background fcopy. (Also, all file transfers should be in -translation binary mode, which isn't the default under windows).
From: Giorgio Valoti on 18 Jun 2010 12:29 On 2010-06-18 17:09:50 +0200, tom.rmadilo said: > […] >> >> I have reduced the problem to line (proc Httpd_ReturnFile on httpd.tcl): >> >> fcopy $in $sock -command [list HttpdCopyDone $in $sock $close] >> >> which copies the contents of the file to the socket. For some reasons >> it blocks when some particular files are requested on Windows XP and >> tclhttpd serves the file from a starkit. > > Is it possible the response code makes another request back to the > same server? I have an application which runs under regular tcl > [socket], but hangs under tclhttpd. I gave up looking for the reason, > but months later considered that I messed up my fcopy command. What I > would look for is an [fcopy] which doesn't go into the background with > a -command option and doesn't place a file into nonblocking mode. It > is also possible that some code, for some reason puts one of the > channels back into blocking mode, or tries to work with either the $in > or $sock channels. Maybe there is some way to monitor channel > configuration changes during a background fcopy. (Also, all file > transfers should be in -translation binary mode, which isn't the > default under windows). Overall, there are three fcopy calls on tclhttp module: one on cgi.tcl and should be not involved in plain file request; the other two are on Httpd_CopyPostData, same thing; the last is the one cited before and it's used on Httpd_ReturnFile: .... set in [open $path] ;# checking should already be done fconfigure $in -translation binary -blocking 1 if {$offset != 0} { seek $in $offset } fconfigure $sock -translation binary -blocking $Httpd(sockblock) set data(infile) $in Httpd_Suspend $sock 0 fcopy $in $sock -command [list HttpdCopyDone $in $sock $close] .... -- Giorgio Valoti
From: tom.rmadilo on 22 Jun 2010 00:51 On Jun 18, 9:29 am, Giorgio Valoti <giorgi...(a)me.com> wrote: > On 2010-06-18 17:09:50 +0200, tom.rmadilo said: > > > > > > > [ ] > > >> I have reduced the problem to line (proc Httpd_ReturnFile on httpd.tcl): > > >> fcopy $in $sock -command [list HttpdCopyDone $in $sock $close] > > >> which copies the contents of the file to the socket. For some reasons > >> it blocks when some particular files are requested on Windows XP and > >> tclhttpd serves the file from a starkit. > > > Is it possible the response code makes another request back to the > > same server? I have an application which runs under regular tcl > > [socket], but hangs under tclhttpd. I gave up looking for the reason, > > but months later considered that I messed up my fcopy command. What I > > would look for is an [fcopy] which doesn't go into the background with > > a -command option and doesn't place a file into nonblocking mode. It > > is also possible that some code, for some reason puts one of the > > channels back into blocking mode, or tries to work with either the $in > > or $sock channels. Maybe there is some way to monitor channel > > configuration changes during a background fcopy. (Also, all file > > transfers should be in -translation binary mode, which isn't the > > default under windows). > > Overall, there are three fcopy calls on tclhttp module: one on cgi.tcl > and should be not involved in plain file request; the other two are on > Httpd_CopyPostData, same thing; the last is the one cited before and > its used on Httpd_ReturnFile: > > ... > set in [open $path] ;# checking should already be done > fconfigure $in -translation binary -blocking 1 > if {$offset != 0} { > seek $in $offset > } So unless this server is handling this connection in an independent thread, it could block the entire server. > fconfigure $sock -translation binary -blocking $Httpd(sockblock) > set data(infile) $in > Httpd_Suspend $sock 0 > fcopy $in $sock -command [list HttpdCopyDone $in $sock $close] Same here: http servers shouldn't block unless they are running threads for each request. If the request makes a request back to itself, you could expect a lockup/stall whatever. Going in and out of blocking mode could be a problem.
From: Giorgio Valoti on 22 Jun 2010 02:58
On 2010-06-22 06:51:08 +0200, tom.rmadilo said: > […] >> the last is the one cited before and >> it's used on Httpd_ReturnFile: >> >> ... >> set in [open $path] ;# checking should already be done >> fconfigure $in -translation binary -blocking 1 >> if {$offset != 0} { >> seek $in $offset >> } > > So unless this server is handling this connection in an independent > thread, it could block the entire server. > >> fconfigure $sock -translation binary -blocking $Httpd(sockblock) >> set data(infile) $in >> Httpd_Suspend $sock 0 >> fcopy $in $sock -command [list HttpdCopyDone $in$sock $close] > > Same here: http servers shouldn't block unless they are running > threads for each request. If the request makes a request back to > itself, you could expect a lockup/stall whatever. > > Going in and out of blocking mode could be a problem. I have configured tclhttpd to run in multithreaded mode, however, if I understand correctly what you say, we should see a lockup when tclhttpd is run with multithreading off. Am I correct? -- Giorgio Valoti |