115560 - PAC: problems with Mac-style line endings

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P3)

Description

[warren jones]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

For Win & Mac OS 9, Mac OS X, Mozilla & Netscape 6.2 ...

I have a standard proxy config script but browser ignores proxies and always
goes direct. Checking the javascript console it reports 

Error: unterminated string literal
Source File: http://foo.com/config.proxy
Line: 256, Column: 19
Source Code:
            return "PROXY proxy.foo.com:8080

One problem here is that there's only approx 40 lines in the proxy config script
- how can it think the problem is on line 256?

The config script work fine on NN4.x.

Reproducible: Always
Steps to Reproduce:
1. Enter in my proxy config script url in proxy prefs
2. go to any web page
3. check js console

Comment 1

[Bradley Baetz (:bbaetz)]

Can you attach your proxy script?

It looks like the error is just what is said - your return statement is missing
a closing ".

Comment 2

[warren jones]

Attachment: proxy auto config file (modified for privacy)

Comment 3

[warren jones]

That's what appears to be the cause but believe me it ain't. 

The script is fine and as I said it works with NN4.x.

Also as I indicated the script is only 40 lines long NOT 256 lines so it looks
like the script is not being read correctly or being corrupted or misinterpreted.

config script sent as attachment

Comment 4

[basic]

my guess is what happened here is that the PAC file was not completely
downloaded for some reason and got truncated. On the other hand the 256 lines
could mean something else is going wrong. Can you try a newer build?

Comment 5

[warren jones]

I've just tried with Mozilla 0.9.7 Gecko/20011221. Same problem.

I think I've always had this problem with all versions of Moz and NS6 that I've 
tried as I don't recall the browser ever using the proxy with my auto script. 
Manually setting a proxy works.

Comment 6

[warren jones]

This bug still persists in the latest released build (0.9.9, Gecko/20020310)

It persists on Mac OS X, Mac OS 9, Win 32.

I can send the unmodified script to any developer privately if they want to test.
I'd like to begin deploying Moz more widely but cannot due to this critical (for
me at least) bug.

Comment 7

[basic]

I think a packet capture/sniff will probably be more helpful in this case.

Comment 8

[basic]

another thing that might help is a "debug" version of the PAC component for you
to test. I'll try to hack one up.

Comment 9

[warren jones]

OK I've now narrowed down the problem.

When the PAC file is served from my standard web server (WebSTAR 3.0.2/MacOS 9)
the problem exists. When served from Apache/Solaris the problem doesn't exist.

My main web server serves every other file OK to Mozilla and serves the same PAC
file OK to other browsers. The problem is a combination of Mozilla receiving
proxy autoconfig files and WebSTAR 3.0.2.

Comment 10

[benc]

wow.
maybe it is packet trace time? a comparison of the exchanges between the two
servers would be nice.

Comment 11

[Boris 'pi' Piwinger]

Is this still happening in 1.0 or later?

pi

Comment 12

[warren jones]

yes. still happening with 1.0 and also with 1.1a

Comment 13

[Boris 'pi' Piwinger]

Any way we could test this?

pi

Comment 14

[benc]

I don't know how easy WebStar is to find these days.

Is the PAC file on a public URL?

Comment 15

[warren jones]

URL is on a public server but would like to keep it private. I'm happy to give
it to a Moz developer privately. Will email to Boris and Ben now.

Comment 16

[Boris 'pi' Piwinger]

Thanks for providing the address. I actually found a problem. When I download
the script it terminates earlier than your attachment. This makes the script bogus.

If I use lynx -dump to download the script, it is OK.

So the mistake is *not* broken parsing, but broken download of the script.

Over to HTTP.

pi

Comment 17

[Boris 'pi' Piwinger]

I double-checked that I had a checkmark for setting NEW. It failed. Once more
confirming the problem.

pi

Comment 18

[Darin Fisher]

i wonder if this is a line ending problem.  MacOS 9 probably sends the document
with \r as the newline character.  what we do is append your PAC file to some JS
script that uses \n as the newline character.  even though JS is not supposed to
care about whitespace, i bet the JS parser might get confused if the line ending
changes part way through the JS script.

i checked attachment 61934 [details] and it does indeed have \r line endings.  so, all we
need to do now is duplicate the problem and verify that we are indeed getting
bitten by mixed line endings.

Comment 19

[Darin Fisher]

back to untargeted...

warren: can you try converting the line endings of your PAC file to DOS style or
UNIX style and see if that solves the problem?  thx!

Comment 20

[warren jones]

Good one!

Mac line ends or DOS line ends in the PAC file give the problem.
Unix line ends work fine without error.

Should have thought to try this one myself.

Comment 21

[Darin Fisher]

hmm, ok, so the webserver is running on MacOS9, and you observed the problem
whenever you ran mozilla from MacOS9, MacOSX, or any version of Windows?

i'll have to check with the PAC spec to see if there are any rules on the line
ending for the script file.  At any rate, it's no surprise to me that you
encountered this problem because the PAC file you download is actually appended
to a javascript file that is included in the mozilla distribution.  the
resulting javascript file is then executed.  most likely, the javascript file
included in the mozilla distribution uses UNIX style line endings, therefore the
one you download has to also have UNIX style line endings.

i think it's reasonable to say that mozilla should be able to deal with PAC
files using non UNIX style line endings, so this is definitely a mozilla bug.

-> future (since we're still looking for someone to own the mozilla PAC feature)

Comment 22

[benc]

I don't think the PAC spec talks about line endings at all. What does javascript
do, in general?

Comment 23

[Darin Fisher]

phil: can you offer any insight to this bug?  or can you cc some folks who might
know.  thanks!

Comment 24

[Phil Schwartau]

Let me cc Roger in case he can add more on this issue. Here is the
ECMA-262 Ed. 3 spec (http://www.mozilla.org/js/language/E262-3.pdf):

7.3 Line Terminators

Like white space characters, line terminator characters are used to
improve source text readability and to separate tokens (indivisible
lexical units) from each other. However, unlike white space characters,
line terminators have some influence over the behaviour of the syntactic
grammar. In general, line terminators may occur between any two tokens,
but there are a few places where they are forbidden by the syntactic grammar.
A line terminator cannot occur within any token, not even a string. Line
terminators also affect the process of automatic semicolon insertion
(section 7.8.5).

The following characters are considered to be line terminators:

Code Point Value           Name             Formal Name
   \u000A               Line Feed               <LF>
   \u000D               Carriage Return         <CR>
   \u2028               Line separator          <LS>
   \u2029               Paragraph separator     <PS>


Syntax

LineTerminator ::
       <LF>
       <CR>
       <LS>
       <PS>

Comment 25

[rogerl (gone)]

Nothing much to add - the scanner (lexer) handles all combinations of \r, \n
etc. etc. without prejudice. The hard and fast rule is that a line-break (by
whatever means) may not occur in a string literal. We need to stop the browser
at the point where the concatenated script arrives and check that it looks fine
there...

Comment 26

[Darin Fisher]

-> default owner

Comment 27

[Patrick McManus [:mcmanus]]

macos line endings aren't a thing to worry about these days.