View Complete Thread | FoxWeb Forum Home
Search:
Date:    Msg ID:   
From:    Thread:   
Subject:   
Sorry for the delay in following up on the forum -- I've been on vacation the last week.
 
Yes, I had some code that was printing a Location: HTTP header with an absolute value (not a fully qualified URI), and the new web server did not like that. Something like this:
 
Location: /foo/bar/login.prg
 
 
As it turns out, the HTTP/1.1 spec does require a full-qualified URI in a Location header, but this is the first web server I've ever worked with that actually bombed on a bad Location header.  I don't understand completely what happened from there, but I think it's something along the lines of the web server not releasing its connection to the FoxWeb channel, even after it severed the connection with the browser. 
 
This is compounded by the fact that FireFox browsers immediately re-send the request after a 408 response, thus instantly consuming all available FoxWeb channels.  IE browsers do not re-send after a 408, but a few manual reloads yield the same result soon enough.
 
I've appeased the new web server by adding the following line to fw_exit.prg:
 
html_out = STRTRAN(html_out, ;
    chr(10) + "Location: /", ;
    chr(10) + "Location: http://" + Request.ServerVariables('SERVER_NAME') + "/")

 
Of course, this only works on legacy code that still uses html_out, but for us, that's a lot of code.  It's also a little sloppy, as it could inappropriately replace instances of "Location: /" within the body of a page, but I'll take that chance.  I plan on going back and fixing each instance of the issue at the source, but this patch seems to have fixed it for all the test cases I've found.
 
THANKS AGAIN to the FoxWeb support team.  Once again, you guys have gone above and beyond the call of duty, helping me debug problems that truly have nothing to do with FoxWeb itself. 
 
YOU GUYS ARE THE BEST!!!
 
--
David Hempy
Internet Database Administrator
Kentucky Educational Television
(859)258-7164 - (800)333-9764
Sent by FoxWeb Support on 10/06/2008 10:59:31 AM:
SOLUTION: As it turns out, the problem was caused by the fact that the Sun Web Server version 7 does not like relative Location HTTP headers. If a Location header does not start with "http://", or "https://" the server immediately returns a 408 HTTP status to the browser.
FoxWeb Support Team
support@foxweb.com email
Sent by David Hempy on 10/01/2008 08:56:12 PM:
I have been running FoxWeb as an application (that is, with the channel windows visible) throughout my testing.  As I said in my first post, the very first line of fw_enter.prg is a print statement, and that statement is not appearing in the channel windows.  Also, the title of the channel windows never changes to reflect a busy status. 
 

I agree with you about the timeout value (I've left it at 15 seconds), but that's not the issue...the error is returned to the browser instantly.
 
This exact code runs just fine on the old hardware...I've done byte-wise compares between the .prg and .fxp files between the two with no discrepancies.  I'm quite certain that my code never gets executed when the Broker gets in this state. There are no dialog boxes, illegal commands, or user inputs.
 
 
Do you have any other suggestions of things I can check for or known issues?  I've been actively developing this site in FoxWeb for over a decade, but I've plumb run out of ideas on this problem.
 
Thanks,
-dave
 
--
David Hempy
Internet Database Administrator
Kentucky Educational Television
(859)258-7164 - (800)333-9764