Content-type

[Jeff Thies]

I'd like to know what content-type the server is sending. In
particular what character set is being used.

Does the server send the content-type by looking at the page extension
(mime types?) Or does it try to read file. The server in question is
probably IIS6.

If I use view info in NS7.1 it reports a character encoding. I'm
thinking that this is probably read from the document, not the char set
sent in the header, but I don't know. I'm unable to find page properties
in Opera and I'm unsure of what IE reports/

I'm still trying to sort this:

<URL: http://paydayusa.com/MainMenu/MainMenu.htm >

This appears to be broken UTF-16LE.

Cheers,
Jeff

 

[Dave Patton]

I'd like to know what content-type the server is sending. In
particular what character set is being used.

I'm still trying to sort this:

<URL: http://paydayusa.com/MainMenu/MainMenu.htm >

Using MiArt's HTTP Header Info Tool:
http://www.miart.co.uk/headertool.htm
HTTP Header Info
--------------------------------
HTTP/1.0 200 OK
Accept-Ranges: bytes
Date: Sun, 11 Jul 2004 19:13:33 GMT
Content-Length: 54448
Content-Type: text/html
Server: Microsoft-IIS/5.0
MicrosoftOfficeWebServer: 5.0_Pub
Last-Modified: Fri, 21 May 2004 17:19:49 GMT
ETag: "3c1c23d2573fc41:92e"
Via: 1.1 px7wh (NetCache NetApp/5.6)

 

[Toby A Inkster]

I'd like to know what content-type the server is sending. In
particular what character set is being used.

It's good to be aware of such things.

Simplest way is to telnet into port 80 of your webserver and enter the
following three lines:
HEAD /full/url/of/file HTTP/1.1
Host: your.domain.name

Note: the third line is blank.

The response will be the full HTTP headers -- including the Content-Type
header.

Does the server send the content-type by looking at the page extension

Often, yes. It depends on how the server has been set up and its
capabilities.

Or does it try to read file.

Sometimes (see the mod_magic module for Apache).

The server in question is probably IIS6.

In that case, probably purely by file extension.

I'm unable to find page properties in Opera

Use the hotlist (or "panels" in 7.5x terminology) and show the "Info"
panel.

I'm still trying to sort this:
<URL: http://paydayusa.com/MainMenu/MainMenu.htm >

Headers:

200 OK
Connection: close
Date: Sun, 11 Jul 2004 20:03:10 GMT
Accept-Ranges: bytes
ETag: "3c1c23d2573fc41:92e"
Server: Microsoft-IIS/5.0
Content-Length: 54448
Content-Type: text/html
Last-Modified: Fri, 21 May 2004 17:19:49 GMT
Client-Date: Sun, 11 Jul 2004 20:07:59 GMT
Client-Peer: 209.16.232.100:80
Client-Response-Num: 1
MicrosoftOfficeWebServer: 5.0_Pub

 

[brucie]

in post: <

I'd like to know what content-type the server is sending. In
particular what character set is being used.

<URL: http://paydayusa.com/MainMenu/MainMenu.htm >

http://www.delorie.com/web/headers.cgi?url=http://paydayusa.com/MainMenu/MainMenu.htm

 

[Art Sackett]

I'd like to know what content-type the server is sending. In
particular what character set is being used.

If you have a copy of lynx handy (as you probably should, for a variety
of reasons):

lynx -head http://www.domain-in-question.tld/

That'll get you the HTTP headers, but it might not get you a charset.
And even if it does somehow get you a charset, there's no guarantee
that it's not being overridden by the document, or by the client
software doing some heuristic nonsense.

 

[Jukka K. Korpela]

lynx -head http://www.domain-in-question.tld/

That'll get you the HTTP headers, but it might not get you a charset.

It will get the charset if and only if the charset is specified in the
HTTP headers (in the Content-Type header).

And even if it does somehow get you a charset, there's no guarantee
that it's not being overridden by the document, or by the client
software doing some heuristic nonsense.

There's a recent discussion in comp.infosystems.www.authoring.html
that has confirmed the observation that no browser is known to violate
the rule that charset specified in HTTP headers takes precedence over any
attempts to specify the charset inside the document itself (e.g., in
a <meta> tag).

If the headers don't specify the charset, browsers are allowed to (and
generally will) use charset specified in a <meta> tag or in some other
way. It gets fairly complex then, and at some point a browser is allowed
to (and generally will) make some wild guess ("use heuristics"),
typically letting the user try different encodings if the presentation
does not look right (but this may well exceed the user's capabilities).