Re: Which Character Set to Specify (UTF-8 or ISO-8859-1) in ASP.NET Pages?

[Mihai N.]

For both redhat.com and amamotocross.com the server HTTP header response
declare Content-Type to be "text/html; charset=UTF-8"
That overrides the meta in the page (according to the web standards)
(In my opinion bad standard idea. Why the web server administrator
at some ISP should have the power to override what I declare in my
file about my file, I don't know!)
As for bankofamerica.com and NBA.COM, they are both clearly American,
and clearly non-technical. I would say "they don't care, and don't have a
clue"

And same for the ones that are inconsistent between the server and the page.
Their stuff works "by mistake" :-)

--
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

[Anthony Jones]

"Mihai N." <nm**************@yahoo.comwrote in message
news:Xn********************@207.46.248.16...

>
For both redhat.com and amamotocross.com the server HTTP header response
declare Content-Type to be "text/html; charset=UTF-8"
That overrides the meta in the page (according to the web standards)
(In my opinion bad standard idea. Why the web server administrator
at some ISP should have the power to override what I declare in my
file about my file, I don't know!)

I don't agree. The purpose of a HTTP-EQUIV meta tag is to substitute for
the header when the resource is being loaded from a non-HTTP source.

For example its useful if your intention for your HTML is that it can be
opened from the windows file system. In such case HTTP headers that might
modify what the browser does (such as how it interprets the octets as
characters) are not available. The HTTP-EQUIV headers allow you to fill in
those details.

Unless you really want to allow the user to save the HTML for reloading
independantly of your web site (a rare requirement) there is no need to use
HTTP-EQUIV headers in ASPX pages.

Instead use real HTTP headers. These can be set using the object exposed by
the ASPX page's Response property.

In the specific case of ContentType and CharSet these can be configured in
the <% @Page line and this is the best place to do this.

--
Anthony Jones - MVP ASP/ASP.NET

[Jordan S.]

<snip>

Regarding:

Instead use real HTTP headers. These can be set using the object exposed
by
the ASPX page's Response property.

How can I view these "real HTTP headers"? Do they appear in the rendered
page's markup? I would like to be able to verify the values sent to the
browser.

I'm working with a Page-derived class served via custom http handler
factory - so there is no physical aspx page to speak of, much less set @Page
directives on the traditional way. So I'm setting properties directly on the
Response object and want to verify that what I set server-side is what the
client is getting.

Thanks.

[Juan T. Llibre]

re:
!How can I view these "real HTTP headers"?

I use ieHTTPheaders :

http://www.blunck.se/iehttpheaders/iehttpheaders.html
It's free for personal use...and is very good.

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Jordan S." <[e-mail] in message news:uc**************@TK2MSFTNGP04.phx.gbl...

<snip>

Regarding:

>Instead use real HTTP headers. These can be set using the object exposed by
the ASPX page's Response property.

How can I view these "real HTTP headers"? Do they appear in the rendered page's markup? I would like to be able to
verify the values sent to the browser.

I'm working with a Page-derived class served via custom http handler factory - so there is no physical aspx page to
speak of, much less set @Page directives on the traditional way. So I'm setting properties directly on the Response
object and want to verify that what I set server-side is what the client is getting.

Thanks.

[Jordan S.]

Perfect! Thanks. I just installed it and it works great.

"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:eO**************@TK2MSFTNGP03.phx.gbl...

re:
!How can I view these "real HTTP headers"?

I use ieHTTPheaders :

http://www.blunck.se/iehttpheaders/iehttpheaders.html
It's free for personal use...and is very good.

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Jordan S." <[e-mail] in message
news:uc**************@TK2MSFTNGP04.phx.gbl...

><snip>

Regarding:

>>Instead use real HTTP headers. These can be set using the object
exposed by
the ASPX page's Response property.

How can I view these "real HTTP headers"? Do they appear in the rendered
page's markup? I would like to be able to verify the values sent to the
browser.

I'm working with a Page-derived class served via custom http handler
factory - so there is no physical aspx page to speak of, much less set
@Page directives on the traditional way. So I'm setting properties
directly on the Response object and want to verify that what I set
server-side is what the client is getting.

Thanks.

[Mihai N.]

I don't agree. The purpose of a HTTP-EQUIV meta tag is to substitute for

the header when the resource is being loaded from a non-HTTP source.

You are entitled to your opinion.
I guess this was also the thinking of the W3C.

But it is bad, and this is why:
The HTTP response header is decided by the HTTP server, bases usually on a
global configuration, controled by the ISP.

The HTTP-EQUIV meta tag is something I add, it applies to the content of
a file that I created, it's mine, and I know way better what's inside.
So why would the ISP decision override mine?

Use case:
1. I have international customers fully Unicode aware.
2. For them I save the html files as UTF-8 (less pain overall)
3. My ISP configured it's server to send ISO-8891-1 in the HTTP response
Why should the ISP decision take precedence over mine?

What is the solution here? Ask the ISP to switch to UTF-8?
They might have thousands of customers that don't care, or the change might
break something for them.
Change the ISP? Ok, possible.

But why all this pain? Because of a bad decision in the standard.
--
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

[Mihai N.]

FWIW: I am the ISP (and therefore have complete administrative access...

IIS7 on Windows Server 2008).

Then you have no problem :-)
But the discution was in principle, why I think the standard got it wrong.
--
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email