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 6091 - Using the 'accept=' url append option returns invalid reusable link.
Summary: Using the 'accept=' url append option returns invalid reusable link.
Status: RESOLVED FIXED
Alias: None
Product: Validator
Classification: Unclassified
Component: Website (show other bugs)
Version: 0.8.3
Hardware: PC Linux
: P2 normal
Target Milestone: 0.8.4
Assignee: Ville Skyttä
QA Contact: qa-dev tracking
URL: http://wolflinux.homelinux.org/bug/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-17 22:32 UTC by Taylor Gresser
Modified: 2009-01-29 16:13 UTC (History)
2 users (show)

See Also:


Attachments

Description Taylor Gresser 2008-09-17 22:32:28 UTC
In short, the "Linking to this result" for my php/xhtml code should return:
http://validator.w3.org/check?uri=http%3A%2F%2Fwolflinux.homelinux.org%2Fbug%2F&accept=application%2Fxhtml%2Bxml;
but instead returns:
http://validator.w3.org/check?uri=http%3A%2F%2Fwolflinux.homelinux.org%2Fbug%2Faccept=application%2Fxhtml%2Bxml;
(missing an '&' before "accept=")

Long version:
I use the following code at the top of each page on my site:

<?php
if(stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")){
        header("Content-Type: application/xhtml+xml; charset=UTF-8");
        echo('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">');
} else {
        header("Content-Type: text/html; charset=UTF-8");
        echo ('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">');
}
?>

This requires me to append "&accept=application%2Fxhtml%2Bxml" to the end of the normal validation string when I want to test xhtml 1.1 validation, and I can leave it off to test xhtml 1.0 strict.

When the validation completes, it returns a link in the "Linking to this result" section to allow easy re-validation. This link leaves out the '&' character, resulting in it attempting to validate the page "http://wolflinux.homelinux.org/bug/accept=application%2Fxhtml%2Bxml", which does not exist.

I'm filing this report on the assumption that this is not the desired behavior. If it is, my apologies.
Comment 1 Ville Skyttä 2008-09-19 21:04:35 UTC
This is hopefully now fixed in CVS, thanks for the catch.

"Hopefully" because I was not able to actually test it as the test case you described triggers something that looks like a DTD related error in XHTML 1.1 mode with the development version of the validator and thus it does not produce a self-referential validation link at all.  But the bug looked pretty obvious.
Comment 2 Taylor Gresser 2008-09-20 18:13:37 UTC
When you say the described test case is causing problems in the development version of the validator, do you mean the validator is having issues with the accept= flag, or something incorrect in the doctype string being used?
Comment 3 Ville Skyttä 2008-09-20 19:18:37 UTC
Neither, but something in the used (XHTML 1.1?) DTD contents upsets the validator, see for example

http://qa-dev.w3.org/wmvs/HEAD/check?uri=http%3A%2F%2Fwolflinux.homelinux.org%2Fbug%2F&charset=(detect+automatically)&doctype=Inline&group=0&accept=application%2Fxhtml%2Bxml

Validation Output:  1 Error

   1. Error Line 4615, Column 0: character "]" not allowed in declaration subset.

Comment 4 Taylor Gresser 2008-09-20 20:21:53 UTC
That makes sense, I think.

http://192.168.1.30/bug/test.php is the same page with no php, and http://192.168.1.30/bug/test2.php is the same page yet again with no doctype string at all. Specifying xhtml1.1 as the doctype results in the same error, and neither of those files contain a ']' character.

http://qa-dev.w3.org/wmvs/HEAD/check?uri=http%3A%2F%2Fwolflinux.homelinux.org%2Fbug%2Ftest.php&charset=utf-8&doctype=XHTML+1.1&group=0&verbose=1&accept=application%2Fxhtml%2Bxml

http://qa-dev.w3.org/wmvs/HEAD/check?uri=http%3A%2F%2Fwolflinux.homelinux.org%2Fbug%2Ftest2.php&charset=utf-8&doctype=XHTML+1.1&group=0&verbose=1&accept=application%2Fxhtml%2Bxml

You've probably already tested that, but I want to try to help out. Anything I can do?
Comment 5 Ville Skyttä 2008-09-21 08:00:48 UTC
Thanks for the offer, but I don't think there's anything more you can do to help at this point.

Meanwhile, I managed to test locally by applying the fix in CVS to the 0.8.3 version of the validator, and it does resolve the issue.