Thanks for your help.
I found two solutions. Both seem to work.
One is to include the header "Connection: close" in the 302-redirect. The
other is to close both STDOUT and STDERR in the child (my original version
was closing only STDOUT, which apparently was not enough).
I found the first one of these solutions the hard way: I wrote a little
proxy script to record the details of the requests sent by Firefox and
Safari. Then I saw that Firefox's request included the header "Keep-alive:
300", whereas the Safari request didn't. This gave me the idea of adding
"Connection: close" to the 302-redirect response. It was a bit of a wild
guess, but it worked.
In retrospect, I wish there had been an easier way for me to inspect the
requests sent by each browser. I asked our sysadmin if there was a way to
configure Apache temporarily (i.e. only for debugging purposes) to record
all requests verbatim, but he did not know how to do this.
What browser-independent Apache tools are there for this type of analysis?
Also, even though the second solution works, I'm mystified by it... It
suggests that Apache sends a different signal back to the browser depending
on exactly which output streams are closed by the child process. That's the
only way to explain the fact that Firefox behaves differently depending on
whether the child closes STDERR or not. Where can I learn more about
Apache's handling of child processes and their output streams?
TIA!
Kynn
On Tue, Oct 7, 2008 at 1:03 AM, <[EMAIL PROTECTED]> wrote:
> 1. Always describe the intended functionality.
> This code creates a session. Most application servers needing
> sessions just send a page with the session in the querystring and a
> Cookie. If subsequent requests do not include the Cookie, the
> querystring is used; otherwise just use the Cookie. A redirect is not
> required -- the first response can add a Cookie and the querystring
> parameter to every local URL. If the Cookie is not found, the
> querystring parameter must be added to every local URL on every page.
> Many websites do not support sessions without Cookies because:
> - changing every local URL on every page is beyond their programmers'
> abilities.
> - URL-based sessions are lost if the visitor opens a page without the
> session parameter (such as using a bookmark or returning after
> visiting another website.)
> Other security concerns include randomization of session identifiers
> and locking the session to an IP Address and User-Agent.
>
> The code seems complicated for no purpose. Why are you forking with
> "expect-more-data"?
>
> 2. Perl Script:
> If no session, redirect with session, exit.
> Else send page.
> For maximum 2 pages seen in Firefox. Why is Safari sending extra requests?
>
> 3. JavaScript:
> Did you see the code in the HTML source? Is an earlier version in cache?
>
> Onload runs setTimeout( 'maybe_refresh()', 3000 );
> function maybe_refresh() {
> // This line never runs.
> // document.images always exists so test is always false.
> // Probably wanted (0 < document.images.length)
> if ( !document.images ) return;
> window.location.reload();
> }
> After fixing the code, an IMG element is required to prevent reload.
>
> Some browsers run onLoad functions when transfer completes but before
> processing the HTML completes so JavaScript expecting HTML objects may
> fail. I add function(s) at the end of the BODY so browsers do not run
> the code until all HTML is processed.
> ...
> <script language="JavaScript">
> setTimeout( 'maybe_refresh()', 3000 );
> </script><./body></html>
>
> 4. If this is not what you wanted, please explain what you are
> attempting. We can assist better when we do not need to guess the
> purpose from reading non-working code.
>
> HTH,
> solprovider
>
>
> On 10/1/08, Kynn Jones <[EMAIL PROTECTED]> wrote:
> > I am trying to debug a large Perl/CGI-based legacy system that is not
> > working right on some browsers, like Firefox 3. It runs on an Ubuntu
> host
> > with Apache 2.2.3.
> >
> > I reduced the problem to a very simple case, in the form of a short Perl
> CGI
> > script. This script has the following logical structure (in pseudo
> code):
> >
> > if called without session ID
> > create new session id
> > use this id to cache a data stub (with "expect-more-data" flag set)
> > fork
> > if parent
> > respond with a 302 redirect whose URL is the script URL + the session
> ID
> > exit
> > if child
> > repeat for i in 1..20
> > sleep 1 second
> > add "i\n" to the cached data
> > unset the "expect-more-data" flag in the cached data object
> > exit
> > else (i.e. session ID available)
> > retrieve cached data
> > if "expect-more-data" flag is set
> > add "...continuing..." at the end of the response
> > add <meta http-equiv="refresh" content="3"/> to the response's header
> > display a page with the newly retrieved data
> >
> > This works fine with Safari, but with Firefox (v. 3), the browser appears
> to
> > be loading for about 20 seconds and then in the end it displays only the
> > last page; none of the intermediate update pages is displayed.
> >
> > If one looks at Apache's access logs, when the request is done via
> Safari,
> > one sees several GET requests logged, right in synch with the page
> updates
> > as they're being displayed by the browser, as expected. But when one uses
> > Firefox, the access log show only two GET requests, the very first one
> and
> > the very last one, and they both appear simultaneously when the last (and
> > only) page is finally displayed. (The error logs do not register any
> > messages during this time.)
> >
> > It was as if the initial request from Firefox was not deemed finalized
> until
> > the very last one was...
> >
> > I thought that perhaps for some reason Firefox was simply dropping all
> the
> > responses that had a <meta http-equiv="refresh" .../> directive in the
> > header. So I decided to implement the same server-browser interaction
> using
> > JavaScript; i.e. I replaced the <meta http-equiv="refresh" .../> tag with
> > the following bit of JavaScript:
> >
> > <script>
> > var delay = 3;
> > var calls = 0;
> > function maybe_refresh() {
> > if ( !document.images ) return;
> > if ( calls > 0 ) {
> > window.location.reload();
> > }
> > else {
> > calls += 1;
> > setTimeout( 'maybe_refresh()', delay * 1000 );
> > }
> > }
> > window.onload = maybe_refresh;
> > </script>
> >
> > Strangely enough, when I did this the observed behavior was exactly the
> same
> > as before: the new script works fine with Safari, but not with Firefox.
> >
> > This pretty much blows my best explanation out of the water. In other
> > words, although it may be minimally plausible that Firefox would be
> > disregarding all the responses from the server that have a <meta
> > http-equiv="refresh".../> tag in them, I don't see how on earth Firefox
> > could reject all those that have the JavaScript snippet shown above,
> without
> > also rejecting all pages that have embedded JavaScript (which definitely
> > does not happen in this case).
> >
> > So I'm completely stumped, and would very much welcome any ideas you may
> > have for troubleshooting this.
> >
> > For one thing I'd like to find out if the problem is with Apache or with
> > Firefox. My hope is that there is some configuration for Apache that
> will
> > cause Firefox to behave the same way that Safari does.
> >
> > Many thanks in advance!
> > Kynnjo
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> " from the digest: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
