f



Safari treats text/html as text/plain

I've been writing a new CGI script to do a sort of session login for some friends.

I'd been testing it mostly with firefox, mozilla and opera, where it works OK, and
so I decided to test it against the other browsers that I have installed on my Mac
Powerbook (10.4.5).  When I tried it with Safari, I was a bit surprised to see it display
the HTML, rather than rendering it.  I ran one of my web-test tools to see exactly
what it was sending, and got this:

: webcat +H http://roaringjelly.org/~jc/acct/login.cgi
HTTP/1.1 200 OK
Date: Mon, 10 Apr 2006 18:58:10 GMT
Server: Apache/2.0.52 (Unix)
Connection: close
Content-Type: text/html charset="utf-8"

<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN' 'http://www.w3.org/TR/html4/strict.dtd'>
<html>
<head>
         <title>66.92.73.254 account login</title>
         <meta http-equiv='Content-Type' content='text/html; charset=utf-8'>
         <link type='text/css' rel='stylesheet' href='style.css'>
</head>
<body>
....

A couple people have looked this over, and we can't see anything that would make
a program think that it's text/plain.  The Content-Type field looks utterly normal,
and convinces other browsers.  There aren't any extra blank lines in the headers.
The type stuff in the HTML is also ignored, but that's understandable if Safari doesn't
believe that it's text/html.

Safari isn't broken this way for other web pages on the same machine.  Thus, I wrote
the above output to the test.html file in the same directory, stripped off the HTTP
headers, downloaded it via Safari, and it works just fine.  In case it's the .cgi header,
I also tried running a few other CGI scripts from the same server that have different
suffixes (.pl, .sh, and no suffix at all), and they worked.  So it's not really Safari that's
broken; there's something about this particular requests that tell it t ignore the
"Content-Type: text/html ..." line.

Does anyone see what the problem might be?  Whatever it is, it's something that
the other browsers don't seem to do.
0
jcsd (12)
4/10/2006 7:19:05 PM
comp.sys.mac.apps 21416 articles. 3 followers. xxx613 (1334) is leader. Post Follow

8 Replies
1018 Views

Similar Articles

[PageSpeed] 41

In article <qvGdnS3V08g3MqfZRVn-uQ@speakeasy.net>,
 John Chambers <jcsd@speakeasy.net> wrote:

> 
> Does anyone see what the problem might be?  Whatever it is, it's something 
> that
> the other browsers don't seem to do.

My version of Safari (2.0.3 417.8) renders a login form.
-- 
W. Oates
 Teal'c: He is concealing something.
 O'Neil: Like what?
 Teal'c: I am unsure, he is concealing it.
0
Warren
4/10/2006 9:05:46 PM
In article <qvGdnS3V08g3MqfZRVn-uQ@speakeasy.net>,
 John Chambers <jcsd@speakeasy.net> wrote:

[...]

   [<http://roaringjelly.org/~jc/acct/login.cgi>]

> When I tried it with Safari, I was a bit surprised to 
> see it display the HTML, rather than rendering it.

FWIW, Safari 2.0.3 under 10.4.5 does *interpret* the HTML on my machine.

Your HTML and CSS aren't valid though. I wouldn't expect this to cause 
Safari to not interpret the HTML, but "garbage in, garbage out" does 
apply. If it doesn't cause this particualr problem, it is guaranteed to 
cause some other problem.

[...]

> Content-Type: text/html charset="utf-8"
> 
> <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN' 
> 'http://www.w3.org/TR/html4/strict.dtd'>
> <html>
> <head>
>          <title>66.92.73.254 account login</title>
>          <meta http-equiv='Content-Type' content='text/html; charset=utf-8'>

There's no point to repeating the Content-Type header in the file itself.

-- 
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

Mac user: "Macs only have 40 viruses, tops!"
PC user: "SEE! Not even the virus writers support Macs!"
0
Sander
4/10/2006 9:15:05 PM
In article <qvGdnS3V08g3MqfZRVn-uQ@speakeasy.net>,
 John Chambers <jcsd@speakeasy.net> wrote:

> I've been writing a new CGI script to do a sort of session login for some 
> friends.
> 
> I'd been testing it mostly with firefox, mozilla and opera, where it works 
> OK, and
> so I decided to test it against the other browsers that I have installed on 
> my Mac
> Powerbook (10.4.5).  When I tried it with Safari, I was a bit surprised to 
> see it display
> the HTML, rather than rendering it.  I ran one of my web-test tools to see 
> exactly
> what it was sending, and got this:
> 
> : webcat +H http://roaringjelly.org/~jc/acct/login.cgi
> HTTP/1.1 200 OK
> Date: Mon, 10 Apr 2006 18:58:10 GMT
> Server: Apache/2.0.52 (Unix)
> Connection: close
> Content-Type: text/html charset="utf-8"

Shouldn't there be a ";" between text/html and charset?

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
0
Barry
4/10/2006 9:31:52 PM
In article <barmar-FB8C24.17315210042006@comcast.dca.giganews.com>,
 Barry Margolin <barmar@alum.mit.edu> wrote:

> In article <qvGdnS3V08g3MqfZRVn-uQ@speakeasy.net>,
>  John Chambers <jcsd@speakeasy.net> wrote:

[...]

> > : webcat +H http://roaringjelly.org/~jc/acct/login.cgi
> > HTTP/1.1 200 OK
> > Date: Mon, 10 Apr 2006 18:58:10 GMT
> > Server: Apache/2.0.52 (Unix)
> > Connection: close
> > Content-Type: text/html charset="utf-8"
> 
> Shouldn't there be a ";" between text/html and charset?

Yes, I noticed that too, but this seems to have been a typo by the OP:

$ curl -I http://roaringjelly.org/~jc/acct/login.cgi
[...]
Content-Type: text/html; charset=UTF-8

-- 
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

Mac user: "Macs only have 40 viruses, tops!"
PC user: "SEE! Not even the virus writers support Macs!"
0
Sander
4/11/2006 10:39:05 AM
In article <user-9995E6.12390511042006@freeloader.wanadoo.nl>,
 Sander Tekelenburg <user@domain.invalid> wrote:

> In article <barmar-FB8C24.17315210042006@comcast.dca.giganews.com>,
>  Barry Margolin <barmar@alum.mit.edu> wrote:
> 
> > In article <qvGdnS3V08g3MqfZRVn-uQ@speakeasy.net>,
> >  John Chambers <jcsd@speakeasy.net> wrote:
> 
> [...]
> 
> > > : webcat +H http://roaringjelly.org/~jc/acct/login.cgi
> > > HTTP/1.1 200 OK
> > > Date: Mon, 10 Apr 2006 18:58:10 GMT
> > > Server: Apache/2.0.52 (Unix)
> > > Connection: close
> > > Content-Type: text/html charset="utf-8"
> > 
> > Shouldn't there be a ";" between text/html and charset?
> 
> Yes, I noticed that too, but this seems to have been a typo by the OP:

Typo?  It looks like he cut/pasted, so I didn't think a typo was likely.

> 
> $ curl -I http://roaringjelly.org/~jc/acct/login.cgi
> [...]
> Content-Type: text/html; charset=UTF-8

Maybe he's already fixed it.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
0
Barry
4/11/2006 7:33:04 PM
Barry Margolin wrote:
>  Sander Tekelenburg <user@domain.invalid> wrote:
>>  Barry Margolin <barmar@alum.mit.edu> wrote:
>>>  John Chambers <jcsd@speakeasy.net> wrote:
>> [...]
>>>> Content-Type: text/html charset="utf-8"
>>> Shouldn't there be a ";" between text/html and charset?
>> Yes, I noticed that too, but this seems to have been a typo by the OP:
> 
> Typo?  It looks like he cut/pasted, so I didn't think a typo was likely.
> 
>> $ curl -I http://roaringjelly.org/~jc/acct/login.cgi
>> [...]
>> Content-Type: text/html; charset=UTF-8
> 
> Maybe he's already fixed it.

Maybe; maybe not.  I tried checking out the origin of the line without
the ';', but found that 1) my code now generates the ';', and 2) the page
now works with Safari.

As so often happens, my thought was "But I haven't changed the code!"
Standard disclaimer.  I had, of course, done a fair amount of tweaking
of other stuff, to try to get some clues.  But the perl code that generates
the header was unchanged:

$charset  = 'UTF-8';
$mimetype = 'text/html';
....
my $cgi = new CGI;
print $cgi->header(
     '-type'    => $mimetype,
     '-charset' => $charset,
     '-expires' => '+30s',
);

The $mimetype var doesn't contain a ';'; it's just 'text/html', and the
$charset var is 'UTF-8'.  I have changed charset back and forth between
'UTF-8' and 'utf-8', as a way of verifying that those 5 chars really were
coming from $charset and not being generated by some subroutine.
I also change the '-expires' value occasionally for the same reason.
But note that no string in my code contains a ';' char, so it is generated
by some subroutine.  At least it is now, though apparently a couple of
days ago it wasn't.

This ';' probably is the problem.  I suppose I have it narrowed down to
some flakiness in the perl CGI module.  I'm not sure how to pin it down
further.  So whatever triggered it will presumably reappear some time
in the future.  I wonder if there's a way to automatically spot it when it
happens again?  The only way I know is to test it with Safari, which is
in my set of test browsers, but far from the only one.  I guess I'll just have
to make a note that Safari is the only browser I have that cares whether
there's a ';' between the MIME type and the charset= chunks, and sudden
failure for Safari to recognize text/html might be because this ';' has
disappeared for some reason.

It's yet another reason why, after prototyping things like this, I tend to
go over it and replace calls on library routines with my own code that
does the low-level operation directly.  It's more efficient to just write the
HTTP headers directly, and it's not subject to this sort of weirdness.

Anyway, thanks to the pointers to that ';'.  It's really hard to see things
like that, especially when most of the browsers don't seem to care whether
it's there or not.

And this is a case where, if I didn't have a Mac available for testing,
I'd never have noticed a problem.  I even tested it against IE on my
wife's Windows box, and it worked fine there without the ';'.  So it's
yet another example of why web testing needs a flock of different
machines, browsers, etc.  I do test against w3c's validator, but
not for every 1-line change to the code, so maybe I'd have found the
problem there eventually.  In this case, though, the obvious first
question is "Why does Safari treat this page differently from the
dozen or so other browsers I'd tried it with?"  So the obvious place
to ask was in a forum where Safari hackers might hang out.
0
John
4/12/2006 2:08:51 PM
In article <m8edndFvMMpplKDZnZ2dnUVZ_sOdnZ2d@speakeasy.net>,
 John Chambers <jcsd@speakeasy.net> wrote:

[...]

> This ';' probably is the problem.  I suppose I have it narrowed down to
> some flakiness in the perl CGI module.  I'm not sure how to pin it down
> further.  So whatever triggered it will presumably reappear some time
> in the future.  I wonder if there's a way to automatically spot it when it
> happens again?

Run your code's output though a HTTP validator. Not that I know of any 
such ready-made tool (nor have I looked), but in essence this seems to 
be about having sanity checks in your code.

> The only way I know is to test it with Safari

Browsers will do everything and anything to make the worst shit appear 
like a fresh Rembrandt. Judging browser output is therefore a completely 
inappropriate method of 'validating' one's code.

[...]

> I guess I'll just have
> to make a note that Safari is the only browser I have that cares whether
> there's a ';' between the MIME type and the charset= chunks

How would you know if a next (or earlier) version of Safari won't feel 
different about semi-colons? Or even if that Safari behaviour is 
affected by other factors, like browser or even network settings? You 
can't rely on browser output for this sort of thing.

-- 
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

Mac user: "Macs only have 40 viruses, tops!"
PC user: "SEE! Not even the virus writers support Macs!"
0
Sander
4/12/2006 7:50:47 PM
Sander Tekelenburg wrote:
> In article <m8edndFvMMpplKDZnZ2dnUVZ_sOdnZ2d@speakeasy.net>,

> Run your code's output though a HTTP validator. Not that I know of any 
> such ready-made tool (nor have I looked), but in essence this seems to 
> be about having sanity checks in your code.

I did a bit of googling, and the phrase "HTTP header validation" does
return millions of hits, but at least the one in the first couple of pages
seem to have little if anything to do with HTTP header validation

> Browsers will do everything and anything to make the worst shit appear 
> like a fresh Rembrandt. Judging browser output is therefore a completely 
> inappropriate method of 'validating' one's code.

Ain't that the truth!  But so far the only way I've found to test HTTP
headers is to feed them to assorted web apps and see if anyone complains.
Digging around w3c.org doesn't seem to turn up any useful clues.

>> I guess I'll just have
>> to make a note that Safari is the only browser I have that cares whether
>> there's a ';' between the MIME type and the charset= chunks
> 
> How would you know if a next (or earlier) version of Safari won't feel 
> different about semi-colons? Or even if that Safari behaviour is 
> affected by other factors, like browser or even network settings? You 
> can't rely on browser output for this sort of thing.

You're right there, too.  So I guess I'm just walking on quicksand, as is
usual for just about anything on the Web.
0
John
4/13/2006 1:13:11 AM
Reply: