Welcome to WebmasterWorld Guest from 35.153.135.60

Forum Moderators: coopster & jatar k & phranque

Message Too Old, No Replies

Bizarre Script Error

Related to browsers?

     
3:12 am on Feb 17, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month

joined:Oct 4, 2001
posts:1277
votes: 17


I kind of doubt anyone is going to have any insight into this, but it's worth a shot...

I have a perl script that works correctly in Internet Explorer but returns an error in Opera.

More specifically, it's a forum script that displays the first page of posts correctly in IE but breaks near the end of the list in Opera.

The error is thrown by the script in response to a non-existent data file, it is not a 500 error. Moreover, the error is happening on the default front page of the forum where no user interaction has been done yet.

The script does not differentiate between user agents so this should be completely impossible. Viewing the page in Opera simply can not cause the script to behave differently.

So the question is, why is it?

4:10 am on Feb 17, 2005 (gmt 0)

Full Member

10+ Year Member

joined:July 23, 2003
posts:228
votes: 0


Hard to say without details. However, the headers sent by the two agents (aside from the UA string) may be different - compare them in detail.
4:31 am on Feb 17, 2005 (gmt 0)

Junior Member

10+ Year Member

joined:Oct 1, 2002
posts:96
votes: 0


Do you have cookies switched on in Opera? The script might do something different if you've got cookies switched off.

What's the actual error message you're getting?

7:33 am on Feb 17, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month

joined:Oct 4, 2001
posts:1277
votes: 17


Thanks guys but you're getting the wrong idea, I'm fluent in perl so I'm aware of all the basics.
12:45 pm on Feb 17, 2005 (gmt 0)

Administrator

WebmasterWorld Administrator coopster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:July 31, 2003
posts:12548
votes: 2


I think you are misunderstanding the direction offered here. Your first message certainly points all flags to a browser-related issue so the direction would be to have a look at the headers sent by each browser as well as what the script is returning. Are you sending a DOCTYPE declaration? Are you allowing quirks mode? The browsers may be reacting to something in the header.
12:34 am on Feb 18, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month

joined:Oct 4, 2001
posts:1277
votes: 17


No offense but that response indicates you not did read my post.

I will quote my own post for your benefit:

The error is thrown by the script in response to a non-existent data file, it is not a 500 error. Moreover, the error is happening on the default front page of the forum where no user interaction has been done yet.

The error is thrown by the script, not by the browser. It is not a rendering error and cannot be related to the doc type or rendering mode.

The error is happening in response to the script attempting to open a data file that does not exist. It attempts to open the data file (apparently) when accessed by Opera but not when accessed by IE.

The script does not differentiate in any way between browsers and, as I said, the user has not interacted with the script at this point.

I posted this question in the hopes that someone as or more experienced in perl has run into this seemingly impossible issue before.

While I appreciate the "intro to web programming" posts, and understand that's primarily what the scripting forums at WW have become about, they're not particularly illuminating ;-)

3:43 am on Feb 18, 2005 (gmt 0)

Administrator

WebmasterWorld Administrator coopster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:July 31, 2003
posts:12548
votes: 2



I will quote my own post for your benefit

No need, we are all quite capable of reading it correctly the first time ;)


where no user interaction has been done yet.

A browser requesting the page is user interaction.


The error is thrown by the script, not by the browser.

Usually is, it's not like the browser is serving up the document. It does, however, send the request which includes header requests and content requirements.


The error is happening in response to the script attempting to open a data file that does not exist. It attempts to open the data file (apparently) when accessed by Opera but not when accessed by IE.

This seems to be your key. Although you have stated that you are not doing some form of browser determination in your code nor processing dependencies based on different browsers, all things seem to be pointing that direction. If the script is not making some form of determination, than it seems either the server itself is or the browser request is.


While I appreciate the "intro to web programming" posts, and understand that's primarily what the scripting forums at WW have become about, they're not particularly illuminating ;-)

IanKelley, we are always willing to help around here. That type of attitude usually doesn't get too many folk responding though. We realize troubleshooting can be time-consuming and frustrating, but please keep an open mind as options are being brought forth. It's all part of the process.

3:49 am on Feb 18, 2005 (gmt 0)

Junior Member

10+ Year Member

joined:Oct 1, 2002
posts:96
votes: 0


Thanks guys but you're getting the wrong idea, I'm fluent in perl so I'm aware of all the basics.

No, Wruppert has the right idea.

It must be one of the HTTP headers Opera sends which makes the script behave differently than it would when using IE. The most obvious header being cookies (HTTP_COOKIE) which I pointed out in my previous post. Besides, if you're fluent in perl then you should be quite capable of finding the code which triggers the "on die" message you're seeing when the page breaks. You can then work backwards to find out under what circumstances it's called.

BTW, it doesn't actually matter what's causing the script to behave differently under Opera. What's important is that there's an error in the code somewhere, or you've simply not installed the script properly.

5:14 pm on Feb 18, 2005 (gmt 0)

Administrator

WebmasterWorld Administrator jatar_k is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:July 24, 2001
posts:15756
votes: 0


In this case I would start at the client side and work back

>> The script does not differentiate in any way between browsers

maybe it should

>> It attempts to open the data file (apparently) when accessed by Opera but not when accessed by IE.

so it seems that it is most definitely something that is spawned specifically by the individual browser.

I would isolate the behaviour down to the line where the two browsers are causing the script to behave differently and then start testing every possible value that is active in the script at that point and see where the difference is.

12:19 am on Feb 19, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month

joined:Oct 4, 2001
posts:1277
votes: 17


I wrote this script years ago. I am not trying to debug it, I worked around the problem before I posted. It is not an overly complex script.

I posted because it is a mystifying situation from a programming perspective. There is no logical way it could be happening.

The key point here, which I have apparently failed to get across, is that this issue cannot possibly have anything to do with the headers the browser is sending.

The script reads some data and then loops through it item by item, during this process it reads some additional data for each item from a flat file database.

The script is going to do this in exactly the same way no matter how it is run (browser or command line). There is no header data (cookies or otherwise) involved in the process.

When viewed in Opera it attempts to access a data file that does not exist.

I agree (jatar) that breaking everything apart and going through step by step is the only way to really figure this out. That's not what I'm trying to do here though, the script is both working and unimportant. I don't have time to hunt down the issue.

My intent was to find out if anyone else had encountered (or heard of) a similar issue, just out of curiosity.

12:32 am on Feb 19, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 18, 2003
posts:1929
votes: 0


Could the same error happen in IE and Opera, but it's just not rendering to the screen and shows up only in the source. Could be because a tag is not closed?..
12:36 am on Feb 19, 2005 (gmt 0)

Administrator

WebmasterWorld Administrator jatar_k is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:July 24, 2001
posts:15756
votes: 0


to be perfectly honest IanKelley I have had similar problems before where there was errant data or something (I wish I always knew) passed in that caused scripts to misbehave for no apparent reason in different browsers.

usually I had to rip them apart and rebuild piece by piece

11:20 am on Feb 19, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member kaled is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 2, 2003
posts:3710
votes: 0


The cause will be a bug in your code that is somehow ignored normally.

Hunting it down should not be that difficult. The problem is consistent and reproducible - if it were intermittent, then you'd have a real problem on your hands.

Some years ago, a program of mine crashed on a clean install of Windows. I tracked the problem down to an error in graphics handling. It was a clear programming fault on my part but it had gone unnoticed on dozens of computers for several years.

Kaled.

3:44 pm on Feb 21, 2005 (gmt 0)

Full Member

10+ Year Member

joined:Oct 18, 2000
posts:256
votes: 0


Does this script use any modules? Is it conceivable that any of these modules are checking the environment and doing I/O if certain variables are present? This would explain why it would work from the commandline and why it opens a file that isn't touched directly by your code.

What I would do is record the full environment and any POST data the browser sent (even if you're not using any of this in your own code) and then try recreating the problem from the commandline by feeding the script the same environment and POST data. You may find a module doing something you didn't expect.