Features in IE7

"Andrew Urquhart" <useWebsiteInSignatureToReply (AT) spam (DOT) invalid> wrote

'Replace' is more accurate. The current document would be replaced in
its entirety by the result of the pseudo-protocol execution. Here's an
example:

...
a href="javascriptoSomething();">Test</a
...

I just tried that example code (including all the function code that I
snipped here for brevity) in Mozilla, and it did nothing. I don't
think there's any way to get the "javascript:" pseudoprotocol to
return a new page as you claim was its original intention.

--
Dan

On 26 Jun 2004 13:44:18 -0700, dan (AT) tobias (DOT) name (Daniel R. Tobias)
wrote:

"Andrew Urquhart" <useWebsiteInSignatureToReply (AT) spam (DOT) invalid> wrote

'Replace' is more accurate. The current document would be replaced in
its entirety by the result of the pseudo-protocol execution. Here's an
example:

...
a href="javascriptoSomething();">Test</a
...

I just tried that example code (including all the function code that I
snipped here for brevity) in Mozilla, and it did nothing. I don't
think there's any way to get the "javascript:" pseudoprotocol to
return a new page as you claim was its original intention.

included at (with fixed linebreaking)

http://jibbering.com/2004/6/javascript.html

and it works for me everywhere similarly.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

On Sun, 27 Jun 2004 01:31:23 -0400, Brian
<usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

And Opera, as configured "out of the box." Though, in both cases, I
think it may only break MIME handling for text/css.

text/plain too.

and IE then changes to be conformant, making Mozilla look very
silly IMO.

Not yet. Did you misunderstand the thread? This is a wish list, not a
list of features that already exist.

No correct mime handling is in Windows XP SP2 as the cited urls above,
this is distinct from any IE7 wish lists.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

On Sun, 27 Jun 2004, Jim Ley wrote:

No [,] correct mime handling is in Windows XP SP2

Well, it comes with a long-winded description. It's a move in the
right general direction, but I'm not convinced that what's described
there is fully compatible with RFC2616.

The description seems hopelessly muddled about the distinction between
the open interworking protocols (HTTP, MIME etc.) and the internal
workings of Windows (filename extensions, Windows shell associations,
ProgIDs etc.).

as the cited urls above,

http://www.microsoft.com/technet/pro...on133121120120
says:

Web developers must change their Web servers to host files, using
^^^^
consistent headers and file name extensions.
^^^^^^^^^^^^^^^^^^^^

But HTTP is completely agnostic about "file name extensions": they
play no direct part in the HTTP transaction. So this seem to be yet
another attempt to impose a proprietary flavour of web, even if the
parts which tighten-up on MIME handling are a long-awaited
improvement.

On Sun, 27 Jun 2004 08:38:30 -0400, Brian
<usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

Jim Ley wrote:
Brian wrote:

And Opera, as configured "out of the box." Though, in both cases,
I think it may only break MIME handling for text/css.

text/plain too.

Sorry for not being clearer while abbreviating my reply. What I meant
was that Moz and Opera only change text/plain to text/css, apparently
catering to broken web servers.

Only they do the same with changing text/plain to various streaming
media types (I also don't agree Apache defaulting unknown files to
text/plain is particularly a bug in apache, it's just a poorly chosen
default which is different.)

I just ran a test, configuring my server to send .html files as
text/plain. Lynx 2.8.3, Firefox 0.8 and Opera 7.5 all displayed plain
text, with no rendering, for urls that corresponded to an .html file.
Only IE 6/WinXP broke the rfc, displaying such urls rendered as HTML
documents. Mind you, I have not upgraded to the latest service pack,
and, given how long upgrades take on dialup, I probably won't anytime
soon. Thus, I cannot test Microsoft's claims.

Aside: I know of no browser which changes text/css to anything else.

This is a wish list, not a list of features that already exist.

No correct mime handling is in Windows XP SP2 as the cited urls
above

Rubbish. How does a file extension relate to a url on the client end?

I don't understand what you're saying now? What particular part is
rubbish? you've just said you've not tested XP SP2 so don't know.

The matching content-type to extension does actually seem logical to
me for downloading files (it's not rendering, the quote about file
extensions is to do with when downloading files) . In windows when set
up an extension you can associate a mime-type with it, so all the
download prohibition is saying is that windows users will need to do
this, this I think is sensible way to ensure the uneducated are
downloading what they think they are (not downloading something of
type text/plain but has an extension of .bat which once saved locally
will result in different actions when clicked on.)

Remember virus propogation is mostly being done by users.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

"Philipp Lenssen" <info (AT) outer-court (DOT) com> wrote in news:2jtplkF15vje7U2@uni-
berlin.de:

There's this page requesting people to add their wishes for IE7.
http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

To have IE be a standalone application, not
"part of the operating system", and coincident
with that, have, at a minimum, both IE and Mozilla
offered as installation choices with MS Windows.

--
Dave Patton
Canadian Coordinator, Degree Confluence Project
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/

On Sun, 27 Jun 2004 11:45:46 -0400, Brian
<usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

Jim Ley wrote:
it's just a poorly chosen default which is different.)

Apache can be configured to use a different default, of course. BTW,
I'm curious: what would you choose as default?

I woulnd't choose one, leave out the content-type header (then
sniffing the content is allowed as per http RFC's)

The matching content-type to extension does actually seem logical
to me for downloading files (it's not rendering, the quote about
file extensions is to do with when downloading files) .

Which is it? Does IE Win sp2 follow the rfc or not?

Choosing if to offer a download link, or prevent downloading is not
against the RFC (since it's not actually acting on the mime-type other
than as it's described, it's just preventing the user from saving it)
So I would say it's not against the RFC, since it trusts the
mime-type, it just doesn' offer the user the opportunity to save it.
At least that's my reading. (text/html for example isn't going to
require a .html or .htm extension, nothing would work, so it's clearly
only about downloaded mime-types not rendered ones)

It seems more sensible for a Windows browser to add a sensible
extension based on the content-type, not determine the content-type
based on what it thinks the file extension is.

To me, that would make more sense yes. However it seems that this is
being used the same way Mozilla stopped showing ALT on tooltips, as a
way to encourage authors from doing something they think is right.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

On Sun, 27 Jun 2004, Brian wrote:

(I also don't agree Apache defaulting unknown files to text/plain
is particularly a bug in apache,

Is there anything in http protocols which says what should happen?

No, I don't believe so. The applicable specs for HTTP >= 1.0 say that
the server SHOULD (not "MUST") supply an appropriate content-type.
So it's arguable that if the server genuinely does not know what type
is appropriate, it could omit the content-type header; however, I
don't know any servers which do that, and frankly I wouldn't know how
to dissuade Apache from supplying one.

RFC2616 then goes on to say that

If and only if the media type is not given by a Content-Type field,
the recipient MAY attempt to guess the media type via inspection of
its content and/or the name extension(s) of the URI used to
identify the resource. If the media type remains unknown, the
recipient SHOULD treat it as type "application/octet-stream".

However, it doesn't seem to go into any further details about what
kind of action they had in mind for "treating it as" octet-stream.

In earlier times, we seem to have pretty much taken it for granted
that the only sensible move in response to octet-stream would be to
propose saving the content to file. But in the original NCSA HTTPD
(unix-based), where filename extensions had no particular meaning to
the OS, there would be all kinds of eclectically-named files like
readme.1st and HOWTO.INSTALL and I don't know what else, and people
soon got fed up of being asked to download these to file before they
could read them. Hence the sloppy default of text/plain seems to have
caught-on, instead of application/octet-stream, and this has persisted
in Apache also.

More recently, however, software from you-know-who has taken to
treating application/octet-stream as "client may guess". The
propriety of that in terms of RFC2616 is rather dubious, to my mind;
but its implications in terms of practical security have surely by now
become evident even to those who weren't able to work it out for
themselves beforehand.

Apache can be configured to use a different default, of course.

Indeed, but there's no i-havent/a-clue content-type: every explicit
content type "means" something; except for octet-stream, which says no
more than "this is a lump of bytes with no particular structure or
semantics", with the implication that recipient should have been told,
"out-of-band", what it's supposed to be good for.

I personally favour made-up content types as being more appropriate
for content which has no registered content type. Regular recipients
of such made-up types could then configure their browser according to
their preferences (e.g to feed one particular type to a custom
application, while saving another particular type to file, and so on):
this works even for MSIE, in the situations where I have tried it.

Caveat: content-types which are handled by browser plugins rather than
by helper applications are harder to deal with; I rate that as a
shortcoming of the client implementation, rather than anything wrong
with the interworking specification.

True, I'm relying on (a literal interpretation of) the msdn link
provided earlier in the thread, in particular the part about file
extensions, which should play no role in content type on the client end.

Right

Which is it? Does IE Win sp2 follow the rfc or not?

I'm also interested in the answer to that. Either MS's page is
misleading, or the implementation must be B.A.D ("broken as
designed").

In any case, the content-type should be definitive, whether the
content-type is markup or binary. If you feel otherwise, then your
complaint is not that Firefox (and Opera; you singled out Firefox
while letting Opera off the hook) do *not* break the protocol.

In defence of the minority browsers, even though I deplore what they
did, I think it's fair to say that they were left with little
alternative in the face of widespread server misconfiguration which in
turn could only be explained by MS's misbehaviour. Now that MS are
cleaning-up their act, then presumably the broken servers[1] will be
cleaning up, and the minority browsers can also cut back on
workarounds for broken servers.

It seems more sensible for a Windows browser to add a sensible
extension based on the content-type,

Absolutely.

I've got a script called something.cgi which, when called with the
first set of parameters, delivers the text/html HTML page containing
<img src="something.cgi?..." ...>. Then, when the browser actions
this <img src=...> tag, the same script is called with a different
parameter, which tells the script to return the image/jpeg. In both
cases the filename extension is .cgi

So what kind of sow's ear is IE going to make of that, based on MS's
description of what they're doing in SP2? At the moment, I don't
know.

You seem to have read more into the MS announcement than I did. I
cannot say that you were wrong to do so, but I understood the note
about content-type as being directed at web server admins,

That's how I read it, too.

I tried to find the page again to reread it, but I cannot
find it anymore.

http://www.microsoft.com/technet/pro...on133121120120

all the best

[1] except for the one which reportedly told their customer that they
"did not support CSS, and had no plans to do so in the future".
(sheesh)

On Sun, 27 Jun 2004 17:55:07 +0100, "Alan J. Flavell"
<flavell (AT) ph (DOT) gla.ac.uk> wrote:

I've got a script called something.cgi which, when called with the
first set of parameters, delivers the text/html HTML page containing
img src="something.cgi?..." ...>. Then, when the browser actions
this <img src=...> tag, the same script is called with a different
parameter, which tells the script to return the image/jpeg. In both
cases the filename extension is .cgi

So what kind of sow's ear is IE going to make of that, based on MS's
description of what they're doing in SP2? At the moment, I don't
know.

I would suggest from the documentation that it would continue working,
the "must match" behaviour is clearly only relevent to downloading of
files.

Unfortunately though after installing XP SP2 RC2I do get the
MIME-SNIFFING etc. registry keys, but mime-sniffing of text/plain into
HTML still seems to happen, so the behaviour is nothing like what is
documented there. unless the RC doesn't actually match the
documentation, and this is only scheduled for the release. but at the
moment it's still completely knackered!

You seem to have read more into the MS announcement than I did. I
cannot say that you were wrong to do so, but I understood the note
about content-type as being directed at web server admins,

That's how I read it, too.

Er, Me too, I think the I failed to explain my point clearly
previously.

http://www.microsoft.com/technet/pro...on133121120120

Yep, I can't see any of the behaviour described here in the current
publically available Release Candidate.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

OK, I have just read your message-id
40deff2e.16475570 (AT) news (DOT) individual.net , but as I had already
prepared this f'up, I think it's still fairly relevant, with just a
couple of adjustments...


On Sun, 27 Jun 2004, Jim Ley wrote:

Choosing if to offer a download link, or prevent downloading is not
against the RFC (since it's not actually acting on the mime-type other
than as it's described, it's just preventing the user from saving it)

MS says this:

___
/

When files are served to the client, Internet Explorer uses the
following pieces of information to decide how to handle the file:

.. File name extension and the corresponding ProgID for the registered
handler of that file name extension.

.. Content-Type from the HTTP header (MIME type) and the corresponding
ProgID for the registered handler of that Content or MIME type.

.. Content-Disposition from the HTTP header.

.. Results of the MIME sniff.

In Windows XP Service Pack 2, Internet Explorer requires that all
file-type information that is provided by Web servers is consistent.

\___

I don't see anything which says that this "enforcement" is restricted
to saving to file, as opposed to rendering.

So I would say it's not against the RFC, since it trusts the
mime-type, it just doesn' offer the user the opportunity to save it.
At least that's my reading.

Could you perhaps focus us more closely onto which bit you're reading?
There's a great expanse of verbiage in there, and it's far from clear
to me just which bits you're relying on. And, as you say that tests
with a Release Candidate were not showing the behaviour described,
we really have very little to go on at the moment, have we?

When it says:

Web servers that do not include the correct Content-Type header with
their files and that use non-standard file name extensions for HTML
pages now have their pages rendered as plain text rather than HTML.

- I'm confused as to which kind of boolean "and" we are dealing with
here. In what was quoted earlier, MS said that "Web developers /must/
.... use consistent filename extensions" (which is completely wrong in
HTTP terms); or is it now trying to say that "non-standard"[1] file
name extensions for HTML files will be just fine so long as the
content type is text/html ? (except that maybe the recipient will be
prevented from saving the HTML to a file??? What fun!!)

[1] According to HTTP specifications there is no such thing as a
"standard" for filename extensions!

(text/html for example isn't going to require a .html or .htm
extension,

I can see some logic in what you're claiming - but this still seems to
be an open question, based on what MS have published.

I already quoted this bit:

Web developers must change their Web servers to host files, using
^^^^
consistent headers and file name extensions.
^^^^^^^^^^^^^^^^^^^^

But later, I found this bit:

You should configure Web servers to use the correct Content-Type
headers. You can also name the files with the appropriate file name
^^^
extension for the application that should handle the file.


Those two versions of the litany seem to me to contradict each other.
One says the [information provider] "must" use consistent file name
extensions, whereas the other implies that they don't *have* to choose
a particular filename extension.

It's all rather confusing.