the following link should display as a web page, but I get raw html.

http://lib.povray.org/collection/blockwall/chrisb%201.1.1/blockwall.html

not sure if this is the case with all links of this type, or what...

happens when clicking on "More Detail" after searching the collection.

Regards,
A.D.B.

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> the following link should display as a web page, but I get raw html.
>
> http://lib.povray.org/collection/blockwall/chrisb%201.1.1/blockwall.html
>
> not sure if this is the case with all links of this type, or what...

It's the case with /all/ HTML documents.  The server software is serving them
with a MIME type of text/plain, and your browser displays them accordingly.  I
posted in p.o-c about this problem back in February, but there doesn't seem to
be anyone maintaining the collection.

I discovered that the documents display correctly in Internet Explorer (at least
through version 8), so the misconfiguration is probably unnoticed by most users.
 (Leave it to Micro$haft to get it right by accident.)

Post a reply to this message

Cousin Ricky <rickysttATyahooDOTcom> wrote:
> I discovered that the documents display correctly in Internet Explorer (at least
> through version 8), so the misconfiguration is probably unnoticed by most users.
>  (Leave it to Micro$haft to get it right by accident.)

It's actually not by accident. Internet Explorer deliberately ignores
the HTTP header protocol and tries instead to guess the right MIME type
by examining the received data itself. For this reason it will display
eg. HTML pages as HTML, image files as images and so on, regardless of
what the HTTP headers claim the MIME type is.

I'm guessing they made it like that because back in the day a good
majority of web servers were misconfigured and were sending files with
the wrong MIME type in the HTTP headers. (For example, while gifs and
jpegs might have been configured on the server side to be sent with the
proper HTTP headers, newer image formats like PNG were typically not,
so the server would by default claim that they were plain text, thus
looking like text garbage when looked with a compliant browser.)

The problem with this is that it breaks the HTTP standard and by being
back then by far the most popular web browser, the majority of web servers
never got configured properly. In fact, many people thought that it was
the other browsers that were broken, and IE the only one that worked
properly. (When in fact the problem was a misconfigured HTTP server, and
IE deliberately hiding the fact.)

Quite fortunately IE lost its popularity (thanks to Microsoft halting its
development for several years, for unknown reasons, causing it to fall
badly behind in implementing the newest standards), which means that more
and more servers had to be configured properly so that they would display
correctly with actual standard-conforming browsers.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Cousin Ricky <rickysttATyahooDOTcom> wrote:
> > I discovered that the documents display correctly in Internet Explorer (at least
> > through version 8), so the misconfiguration is probably unnoticed by most users.
> >  (Leave it to Micro$haft to get it right by accident.)
>
> It's actually not by accident. Internet Explorer deliberately ignores
> the HTTP header protocol and tries instead to guess the right MIME type
> by examining the received data itself. For this reason it will display
> eg. HTML pages as HTML, image files as images and so on, regardless of
> what the HTTP headers claim the MIME type is.
>
> I'm guessing they made it like that because back in the day a good
> majority of web servers were misconfigured and were sending files with
> the wrong MIME type in the HTTP headers. (For example, while gifs and
> jpegs might have been configured on the server side to be sent with the
> proper HTTP headers, newer image formats like PNG were typically not,
> so the server would by default claim that they were plain text, thus
> looking like text garbage when looked with a compliant browser.)
>
> The problem with this is that it breaks the HTTP standard and by being
> back then by far the most popular web browser, the majority of web servers
> never got configured properly. In fact, many people thought that it was
> the other browsers that were broken, and IE the only one that worked
> properly. (When in fact the problem was a misconfigured HTTP server, and
> IE deliberately hiding the fact.)
>
> Quite fortunately IE lost its popularity (thanks to Microsoft halting its
> development for several years, for unknown reasons, causing it to fall
> badly behind in implementing the newest standards), which means that more
> and more servers had to be configured properly so that they would display
> correctly with actual standard-conforming browsers.
>
> --
>                                                           - Warp

it also seems to be serving the images as raw binary, because every time I click
on an example image, it wants me to choose an application to handle it.

Is the server running Apache or IIS?

Regards,
A.D.B.

Post a reply to this message

On 10/25/2012 09:31 PM, Anthony D. Baye wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> Cousin Ricky <rickysttATyahooDOTcom> wrote:
>>> I discovered that the documents display correctly in Internet Explorer (at least
>>> through version 8), so the misconfiguration is probably unnoticed by most users.
>>>   (Leave it to Micro$haft to get it right by accident.)
>>
>> It's actually not by accident. Internet Explorer deliberately ignores
>> the HTTP header protocol and tries instead to guess the right MIME type
>> by examining the received data itself. For this reason it will display
>> eg. HTML pages as HTML, image files as images and so on, regardless of
>> what the HTTP headers claim the MIME type is.
>>
>> I'm guessing they made it like that because back in the day a good
>> majority of web servers were misconfigured and were sending files with
>> the wrong MIME type in the HTTP headers. (For example, while gifs and
>> jpegs might have been configured on the server side to be sent with the
>> proper HTTP headers, newer image formats like PNG were typically not,
>> so the server would by default claim that they were plain text, thus
>> looking like text garbage when looked with a compliant browser.)
>>
>> The problem with this is that it breaks the HTTP standard and by being
>> back then by far the most popular web browser, the majority of web servers
>> never got configured properly. In fact, many people thought that it was
>> the other browsers that were broken, and IE the only one that worked
>> properly. (When in fact the problem was a misconfigured HTTP server, and
>> IE deliberately hiding the fact.)
>>
>> Quite fortunately IE lost its popularity (thanks to Microsoft halting its
>> development for several years, for unknown reasons, causing it to fall
>> badly behind in implementing the newest standards), which means that more
>> and more servers had to be configured properly so that they would display
>> correctly with actual standard-conforming browsers.
>>
>> --
>>                                                            - Warp
>
> it also seems to be serving the images as raw binary, because every time I click
> on an example image, it wants me to choose an application to handle it.
>
> Is the server running Apache or IIS?

Apache ... the server runs on FreeBSD unix

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> It's actually not by accident. Internet Explorer deliberately ignores
> the HTTP header protocol and tries instead to guess the right MIME type
> by examining the received data itself. For this reason it will display
> eg. HTML pages as HTML, image files as images and so on, regardless of
> what the HTTP headers claim the MIME type is.
>
> I'm guessing they made it like that because back in the day a good
> majority of web servers were misconfigured and were sending files with
> the wrong MIME type in the HTTP headers. (For example, while gifs and
> jpegs might have been configured on the server side to be sent with the
> proper HTTP headers, newer image formats like PNG were typically not,
> so the server would by default claim that they were plain text, thus
> looking like text garbage when looked with a compliant browser.)
>
> The problem with this is that it breaks the HTTP standard and by being
> back then by far the most popular web browser, the majority of web servers
> never got configured properly. In fact, many people thought that it was
> the other browsers that were broken, and IE the only one that worked
> properly. (When in fact the problem was a misconfigured HTTP server, and
> IE deliberately hiding the fact.)

Similarly (though in the opposite direction), Netscape 4, one of the two
buggiest Web browsers ever written (the other was IE3), lasted years longer than
it ever deserved to, because Web authors kept programming around its bugs.  It's
hard to blame the Web authors, because no one wants their Web pages to be
screwed up by a popular user agent.  But because they inadvertently covered for
Netscape, the end users never learned what a piece of crap they had on their
desktops.

I have to side with the standards.  If I'm doing it wrong, I want to know.
Micro$haft does me no favors by giving me a false sense of security.

Perhaps it's because of my programming background, where I'm used to the
computer doing exactly as I tell it, not necessarily what I intend.  More
likely, it's because of my experiences with Micro$haft since 1997, and more
recently with The Google and with KDE's KWrite: when computer programs
second-guess me, they USUALLY GUESS WRONG.

I appreciate a /warning/ if the program senses that I'm about to do something
regrettable or irrational.  The most obvious example of this is "Document is not
saved. [Save] [Discard] [Cancel]"  Similarly, I appreciate a search engine's
/suggestion/ if I misspell a word.  But don't /guess/ what I want and then
follow through summarily.

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> it also seems to be serving the images as raw binary, because every time I click
> on an example image, it wants me to choose an application to handle it.

This happens to me only with Firefox.  Opera and Konqueror display them normally
(and Opera reports the expected MIME type).  I don't have Safari, and I'll have
to reboot to test it in Chrome (or break down and download it for my current
OS).

When I closed Konqueror, though, it informed me that I had unsubmitted changes.
This was unrelated to clicking on the image or the More Detail link.

Post a reply to this message

Cousin Ricky <rickysttATyahooDOTcom> wrote:
> I appreciate a /warning/ if the program senses that I'm about to do something
> regrettable or irrational.  The most obvious example of this is "Document is not
> saved. [Save] [Discard] [Cancel]"  Similarly, I appreciate a search engine's
> /suggestion/ if I misspell a word.  But don't /guess/ what I want and then
> follow through summarily.

I have never understood the idea with spelling autocorrection that's turned
on by default in most modern smartphones. It's completely useless and it
messes up whatever you want to write most of the time, especially if you
are bilingual (like in my case, where I sometimes write messages in Finnish
and sometimes in English.) Even if you use just one language, it still
manages to mess up many things you write.

The major problem is that it autocorrects without asking. It's not like
it *suggests* a "proper spelling" and allows you to select it. No, it
inserts its suggestion without asking when you press space after the word.
If it guessed wrong, you have to go back and try to fix it (which becomes
hard if you don't know how to bypass the automatic "correction").

-- 
                                                          - Warp

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> it also seems to be serving the images as raw binary, because every time I click
> on an example image, it wants me to choose an application to handle it.

This does not happen with Google Chrome.

Post a reply to this message

On 25/10/2012 17:32, Anthony D. Baye wrote:
> the following link should display as a web page, but I get raw html.
> 
> http://lib.povray.org/collection/blockwall/chrisb%201.1.1/blockwall.html
> 
> not sure if this is the case with all links of this type, or what...
> 
> happens when clicking on "More Detail" after searching the collection.

This is intentional; anything under /collection/ is treated specially
as it is user-submitted content. Potentially a third-party could embed
scripts or malicious code into a submission, so the server has been
instructed to not serve them as HTML.

-- Chris

Post a reply to this message