This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 838 - Upload Validation doesn't work on IE6 SP2 (WinXP SP2)
Summary: Upload Validation doesn't work on IE6 SP2 (WinXP SP2)
Status: RESOLVED INVALID
Alias: None
Product: Validator
Classification: Unclassified
Component: check (show other bugs)
Version: 0.6.7
Hardware: Other Windows XP
: P1 blocker
Target Milestone: 0.7.0
Assignee: feedsho
QA Contact: qa-dev tracking
URL: http://www.lavacochesnely.es/
Whiteboard:
Keywords:
: 903 907 911 914 924 936 951 1010 1013 (view as bug list)
Depends on:
Blocks: 856
  Show dependency treegraph
 
Reported: 2004-08-14 10:20 UTC by Reuben Chew
Modified: 2017-04-28 16:10 UTC (History)
18 users (show)

See Also:


Attachments
bugcatcher (1.43 KB, patch)
2007-01-27 01:59 UTC, Mary-Beth Heisner
Details
feedsho (873.86 KB, patch)
2012-07-27 21:17 UTC, feedsho
Details
feedsho (873.86 KB, patch)
2012-07-27 21:27 UTC, feedsho
Details

Description Reuben Chew 2004-08-14 10:20:19 UTC
It seems that due to XP SP2's MIME type restrictions, when using Internet 
Explorer 6 SP2 to validate documents, it will spit out this error:
-----------------------------------
Sorry, I am unable to validate this document because its content type is 
text/plain, which is not currently supported by this service. 

The Content-Type field is sent by your web server (or web browser if you use 
the file upload interface) and depends on its configuration. Commonly, web 
servers will have a mapping of filename extensions (such as ".html") to MIME 
Content-Type values (such as text/html). 

That you recieved this message can mean that your server is not configured 
correctly, that your file does not have the correct filename extension, or that 
you are attempting to validate a file type that we do not support yet. In the 
latter case you should let us know that you need us to support that content 
type (please include all relevant details, including the URL to the standards 
document defining the content type) using the instructions on the Feedback 
Page. 
----------------------------------
I have asked my friend to test out, and he is using Windows XP SP2 as well. He 
reports the same problem. Meanwhile, using Mozilla Firefox and Opera doesn't 
result in any problem.

Do you guys experience this problem as well? It's a major blocker... Also, on 
another note, I hope PHP files can be validated soon as well.
Comment 1 David Dorward 2004-09-07 21:21:25 UTC
This has been mentioned a few times, I'm not sure if there are other instances
floating around Bugzilla.

The problem is with Windows, not with the Validator so I think this bug in
invalid, or possibly one which should be resolved with a specific mention of the
Windows issue in the error message.

I came across
http://www.lachy.id.au/blogs/log/2004/09/validating-xhtml-with-ie-using-file on
USENET which looks like a possible fix for Windows. (I haven't tested it as I do
not have easy access to a copy of Microsoft Windows).

As for PHP files, these cannot be validated as they are program source code and
not markup - as such the concept of validation is meaningless when applied to PHP.
Comment 2 Bj 2004-09-07 21:34:55 UTC
This should be solved through better UI that makes it easy to use the file 
upload feature in case of browsers sending an unexpected MIME type or no MIME 
type at all.
Comment 3 Olivier Thereaux 2004-09-07 22:18:21 UTC
I would not want to add a "force content-type" option for the sole purpose of accomodating a borken 
browser, but that could be of interest to compare e.g files served as text/html and application/
xhtml+xml.

I'd wait until the IE bug is acknowledged, or, better, fixed in some development version, before adding 
such an option, though...
Comment 4 Terje Bless 2004-09-11 13:33:10 UTC
We'll need to ability to set the Content-Type for fragment validation in any case, and we should be
able to treat this similarly to other widgets (DOCTYPE, Charset) by issuing a warning on mismatches
and other suboptimal behaviour.

I'm somwhat ambivalent about how and if we should react specificly to  XPSP2; this is a long
standing problem, but XPSP2 may exacerbate it sufficiently for us to react.

I wonder if we should issue a note in the news section on :80 that explains the situation with XPSP2
and mentions that we haven't decided what to do about it yet.


Adding blocker on Bug #856 and targetting 0.7.0; until we figure out the "what", "if", and "when" of it.
Comment 5 niq 2004-09-20 21:01:28 UTC
Suggested fix: the error message should point to the fix David mentioned (which
has been floating around since they inflicted SP2 on us).

"If you are using MSIE with XP SP2, there is a fix at .... .  Alternatively, use
a browser with better standards support ...."
Comment 6 Olivier Thereaux 2004-10-06 09:44:26 UTC
*** Bug 903 has been marked as a duplicate of this bug. ***
Comment 7 Ville Skyttä 2004-10-10 11:45:50 UTC
*** Bug 907 has been marked as a duplicate of this bug. ***
Comment 8 Olivier Thereaux 2004-10-12 02:38:14 UTC
*** Bug 911 has been marked as a duplicate of this bug. ***
Comment 9 Ville Skyttä 2004-10-12 14:36:03 UTC
*** Bug 914 has been marked as a duplicate of this bug. ***
Comment 10 Olivier Thereaux 2004-11-09 21:30:01 UTC
*** Bug 936 has been marked as a duplicate of this bug. ***
Comment 11 Terje Bless 2004-11-28 16:06:25 UTC
*** Bug 924 has been marked as a duplicate of this bug. ***
Comment 12 Terje Bless 2004-11-29 15:15:19 UTC
*** Bug 951 has been marked as a duplicate of this bug. ***
Comment 13 Tex Texin 2005-01-09 10:16:01 UTC
This bug has been around for 3 months.The suggestion to mention the lachy site 
is a good one. Failing that, at least acknowledge in the error message that 
there is a problem with IE sp2. Doing so would at least save the increasing 
number of Windows XP SP2 users that run into it, the hassle of digging around 
for the answer, and those that don't dig, from drawing the incorrect conclusion 
that the W3C's validator doesn't work.

Comment 14 Olivier Thereaux 2005-01-15 03:35:46 UTC
*** Bug 1010 has been marked as a duplicate of this bug. ***
Comment 15 Ville Skyttä 2005-01-19 18:37:52 UTC
*** Bug 1013 has been marked as a duplicate of this bug. ***
Comment 16 Robert Chapin 2005-01-19 19:16:08 UTC
Rather than implementing a Content-Type override, why can't the http-equiv tag
be properly recognized?  That would seem to be an obvious solution.
Comment 17 Bj 2005-01-19 20:25:49 UTC
That would require to look for <meta> elements in plain text documents, that is 
not exactly technically sound.
Comment 18 Robert Chapin 2005-01-19 23:38:19 UTC
I realize the Content-Type header is more useful for specifying a character
encoding, but the point is if a user uploads a perfectly valid HTML file and it
does not get validated, then it could be argued the Validator is broken, and not
the browser.
Comment 19 Tex Texin 2005-01-20 08:57:38 UTC
Well, I am a little perplexed as to the concern for looking for a meta 
statement. If someone updates a plain text file to be validated by a tool that 
is expecting either HTML or XHTML, finding a META statement in there, or for 
that matter simply treating the file as markup, isn't going to do any real 
harm. I assume that a validator is written to be prepared for all sorts of 
incorrect markup. Why not just process the file as if it were xml or html, give 
a warning about the content-type, and if suitable initial markup isn't found 
within a reasonable # of lines, bail out, otherwise continue as if the content
-type were specified?

I am concerned that since this has been around for several months, users that 
run into this a) are going off to use other validators, or of more concern b) 
people will opt to simply not validate and as a result many more ill-formed 
pages are being added to the web.
Comment 20 Ville Skyttä 2005-01-20 19:32:20 UTC
...or c) ask their vendor to fix bugs in their software or d) choose to use a
more standards compliant product?  (Yeah, sadly this is probably just daydreaming.)

---

While at it, some food for thought:

A "perfectly valid HTML document" per comment 18:
http://qa-dev.w3.org/~ville/perfectly-valid.exe

And here's a perfectly valid plain text document:
http://qa-dev.w3.org/~ville/perfectly-valid.txt
Comment 21 Bj 2005-01-20 20:54:09 UTC
"An example of incorrect and dangerous behavior is a user-agent that reads some 
part of the body of a response and decides to treat it as HTML based on its 
containing a <!DOCTYPE declaration or <title> tag, when it was served as 
text/plain or some other non-HTML type." -- 
http://www.w3.org/2001/tag/2002/0129-mime

I nevertheless agree with the behavior Tex suggests...
Comment 22 Linguar Amadala 2005-01-27 14:58:55 UTC
(In reply to comment #1)
> This has been mentioned a few times, I'm not sure if there are other instances
> floating around Bugzilla.
> The problem is with Windows, not with the Validator so I think this bug in
> invalid, or possibly one which should be resolved with a specific mention of 
the
> Windows issue in the error message.
> I came across
> http://www.lachy.id.au/blogs/log/2004/09/validating-xhtml-with-ie-using-file 
on
> USENET which looks like a possible fix for Windows. (I haven't tested it as I 
do
> not have easy access to a copy of Microsoft Windows).
> As for PHP files, these cannot be validated as they are program source code 
and
> not markup - as such the concept of validation is meaningless when applied to 
PHP.

I'm in a computer science class as it is, and we were surprised to find that 
our new computers just updated at the start of the semester, were unable to use 
the Validation service because of this same bug.

The side effects of your 'fix' are too great and might lead the professor or 
passerby's to think that things are awry.  404 errors that IE normally handles 
end up giving dll errors, sometimes causing IE to stop responding normally.  In 
effect breaking the active session should too many of these occur during that 
session (back/forward stop working).

If you guys could suggest a better solution, me, and the class I'm taking part 
in would appreciate it.

The professor finds it annoying that she can't give an example of how to 
validate your file(s).
Comment 23 Olivier Thereaux 2005-02-02 05:21:23 UTC
Quoting Peter Normann, who contacted me on the issue:

> The validate by file upload feature of the AIS accessibility toolbar from
> http://www.nils.org.au/ais/index.html somehow bypasses windows alleged
> security stuff responsible for the caveat.

This technique (which I have not tested) has been added to the list of "potential" workarounds in http://
www.w3.org/QA/2005/01/Validator-IE_WinXP_SP2.html
Comment 24 Olivier Thereaux 2005-02-08 21:40:14 UTC
This issue was addressed (by Microsoft) as part of the updates made available today (2005-02-09) for 
Windows XP SP2. 

Would appreciate if IE/WinXP users could confirm whether the issue is gone when applying the updates.
Comment 25 Bj 2005-02-09 01:15:10 UTC
I can confirm that MS05-014 fixes this issue.
Comment 26 Joseph Witthuhn 2005-02-09 22:58:28 UTC
This was never a bug with the validator to begin with, but now it has been 
fixed by Micrsoft's latest round of patches (I got them off of Windows Update, 
users with Automatic Updates should get them too), issued yesterday.
Comment 27 Mary-Beth Heisner 2007-01-27 01:59:02 UTC
Created attachment 450 [details]
bugcatcher
Comment 28 William Clelland III 2009-02-09 12:25:33 UTC
I just approved the distribution of my remark about service pack 3 (three) for Windows XP Professional, on my DELL return-from-lease. My attempts at validation as XHTML 1.0 transitional ALL FAILED via the UPLOAD FROM FILES option and the diagnostics were calling the files HTML 4.01, even the files which were previously OK, and no changes.....  HOWEVER, on my other computer (Win XP HOME edition, SP3) the validation for the same files, was perfect and I have no trouble with UPLOAD FROM FILES option. Therefore the jury is out and I cannot register complaints at this time about the SP3 influence or lack of same. Please forgive my premature comments made prior to thorough checking.
Bill C
Comment 29 feedsho 2012-07-27 21:17:56 UTC
Created attachment 1163 [details]
feedsho
Comment 30 feedsho 2012-07-27 21:27:13 UTC
Created attachment 1164 [details]
feedsho