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 <kynnjo@xxxxxxxxx> 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: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|