W3C's HTML validator unable to find PHP or content negotiated files?

[Chris Simon]

A bit puzzled by this...
1. Ask the validator to look at http://www.nantperis.org.uk/index.php.en
(the exact filename of the page) and it brings back an error: 300
Multiple Choices.

I could understand that if the filename was specified without the .en as
there are more than one version of the page in different languages. Is
it stripping the .en? Has anyone managed to get it to find a .en file
or is it a bug I should report?

2. Ask it to validate http://www.nantperis.org.uk/history/church.php,
again the exact filename of the file, I get a 404 Not Found. Again, is
this a bug?
Both the W3C's CSS Validator and Bobby can find both files, even if you
don't include the file extensions so that the server does the job of
returning the correct file.

Would be grateful for comments.

--
Chris Simon
os******@slcszetnet.co.uk
http://www.users.zetnet.co.uk/csimon/

** Get rid of all SLCs to reply directly **

[Neal]

On Tue, 16 Nov 2004 19:49:52 +0000, Chris Simon
<os******@sclszetnet.co.uk> wrote:

A bit puzzled by this...
1. Ask the validator to look at http://www.nantperis.org.uk/index.php.en
(the exact filename of the page) and it brings back an error: 300
Multiple Choices.

I could understand that if the filename was specified without the .en as
there are more than one version of the page in different languages. Is
it stripping the .en? Has anyone managed to get it to find a .en file
or is it a bug I should report?

2. Ask it to validate http://www.nantperis.org.uk/history/church.php,
again the exact filename of the file, I get a 404 Not Found. Again, is
this a bug?

Let me guess - Windows XP?

[Neal]

On Tue, 16 Nov 2004 14:53:17 -0500, Neal <ne*****@yahoo.com> wrote:

On Tue, 16 Nov 2004 19:49:52 +0000, Chris Simon
<os******@sclszetnet.co.uk> wrote:

A bit puzzled by this...
1. Ask the validator to look at
http://www.nantperis.org.uk/index.php.en (the exact filename of the
page) and it brings back an error: 300 Multiple Choices.

I could understand that if the filename was specified without the .en
as there are more than one version of the page in different languages.
Is it stripping the .en? Has anyone managed to get it to find a .en
file or is it a bug I should report?

2. Ask it to validate http://www.nantperis.org.uk/history/church.php,
again the exact filename of the file, I get a 404 Not Found. Again, is
this a bug?

Let me guess - Windows XP?

Retracted - it does this for me as well.

I don't know the reason, but both pages validate when I run it off my
downloaded source in Opera.

[Chris Simon]

Neal wrote:

Let me guess - Windows XP?

Yes, actually!

You've since said that this is not the problem but out of curiosity, why
would this make a difference? Is there some strange known problem using
the validator with XP? I can think of the firewall....but every other
page I've got is found perfectly OK. This is the first time I've
uploaded content negotiated and PHP pages and they are the only pages
that are not found.

--
Chris Simon
os******@slcszetnet.co.uk
http://www.users.zetnet.co.uk/csimon/

** Get rid of all SLCs to reply directly **

[Neal]

On Tue, 16 Nov 2004 20:01:18 +0000, Chris Simon
<os******@sclszetnet.co.uk> wrote:

Neal wrote:

Let me guess - Windows XP?

Yes, actually!

You've since said that this is not the problem but out of curiosity, why
would this make a difference?

There's a known bug with XP and the validator. It's been posted here
often. I took a wild guess here, but if it's affecting me too, it cannot
be that bug.

As I could validate from my cache, but not from your server, I suspect the
server is not serving the content properly. This is, however, way out of
my league, so I can't help you further.

[Alan J. Flavell]

On Tue, 16 Nov 2004, Chris Simon wrote:

A bit puzzled by this...
1. Ask the validator to look at
http://www.nantperis.org.uk/index.php.en (the exact filename of the
page) and it brings back an error: 300 Multiple Choices.
If you go to the advanced validation menu, and type in the
URL of your page as above, -and- click on the "validate error pages"
and "show source" boxes, then you get this:

1: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
2: <HTML><HEAD>
3: <TITLE>300 Multiple Choices</TITLE>
4: </HEAD><BODY>
5: <H1>Multiple Choices</H1>
6: The document name you requested (<code>/index.php.en</code>) could
not be found on this server.
7: However, we found documents with names similar to the one you
requested.<p>Available documents:
8: <ul>
9: <li><a href="/index.html.cy">/index.html.cy</a> (common basename)
10: <li><a href="/index.html.en">/index.html.en</a> (common basename)
11: </ul>
12: </BODY></HTML>

If you ask to validate -this- URL:

http://www.nantperis.org.uk/index.html.en

then it works. "Hence or otherwise deduce...".

Has your server got mod_speling enabled, perhaps?
I could understand that if the filename was specified without the
.en as there are more than one version of the page in different
languages. Is it stripping the .en?
Absolutely not. You can see the .en clearly in the URL mentioned in
the validator's report.
Has anyone managed to get it to find a .en file or is it a bug I
should report?
The validator isn't interested in the "file" name, it's only
interested in its MIME content-type (and that's the same for every
self-respecting World Wide Web client - it's a mandatory feature of
RFC2616).

[cue the usual rant about the operating system component that
thinks it's a browser... but that doesn't seem to be part of
this particular problem.]
2. Ask it to validate
http://www.nantperis.org.uk/history/church.php, again the exact
filename of the file, I get a 404 Not Found.

I don't immediately have the answer for this one, sorry.

[Chris Simon]

Alan J. Flavell wrote:

If you ask to validate -this- URL:

http://www.nantperis.org.uk/index.html.en

then it works.
OMG - so it does!
Has your server got mod_speling enabled, perhaps?

No idea, but I've just done a Google on this and found that you can turn
it off with CheckSpelling Off in .htaccess. I tried that, but then got
Internal Server Error on trying to access any page! Anyway, as long as
I know to specify html instead of php then it's OK. Many thanks for
that pointer.

2. Ask it to validate
http://www.nantperis.org.uk/history/church.php, again the exact
filename of the file, I get a 404 Not Found.

I don't immediately have the answer for this one, sorry.

OK - thanks for thinking about it.

--
Chris Simon
os******@slcszetnet.co.uk
http://www.users.zetnet.co.uk/csimon/

** Get rid of all SLCs to reply directly **

[Dave Patton]

Chris Simon <os******@sclszetnet.co.uk> wrote in
news:41**********************@master.news.zetnet.n et:

A bit puzzled by this...

1. Ask the validator to look at http://www.nantperis.org.uk/index.php.en
(the exact filename of the page) and it brings back an error: 300
Multiple Choices.
That's not what I get using Firefox. If I look at the HTTP headers,
via the LiveHTTPHeaders Firefox extension, or via:
http://www.delorie.com/web/headers.html
I don't see the 300 response from your server, so I'd guess it's
dependant on the HTTP headers sent by the W3C validator. My(limited)
understanding of content negotiation tells me that it's a valid
response, but maybe the W3C validator should list the choices
(the list should have been sent by your server), so you can select
one to validate.
2. Ask it to validate http://www.nantperis.org.uk/history/church.php,
again the exact filename of the file, I get a 404 Not Found. Again, is
this a bug?

You aren't alone on this one:
http://thread.gmane.org/gmane.org.w3c.validator/3520
In that thread they indicate the problem is related to
"Accept-Language: *", so maybe that's what the W3C Validator sends?

Then again, I just tried something, and it's working now,
so you must have changed something?

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

[Chris Simon]

Dave Patton wrote:

That's not what I get using Firefox. If I look at the HTTP headers,
via the LiveHTTPHeaders Firefox extension, or via:
http://www.delorie.com/web/headers.html
I don't see the 300 response from your server, so I'd guess it's
dependant on the HTTP headers sent by the W3C validator.
Well, I've been playing around in the last hour or so with my web
hosting control panel, and it has a setting for indexes, i.e. whether
the server should return a list of files in a directory if there is no
index file. I turned them off, but found that broke the site for some
reason. I turned them back on again, and now I find that it all works.
I'm completely baffled. Perhaps it's now working, so in fact it's not
sending a 300 any more so you're not seeing that now.
My(limited)
understanding of content negotiation tells me that it's a valid
response, but maybe the W3C validator should list the choices
(the list should have been sent by your server), so you can select
one to validate.
As far as I can see, the server shouldn't have returned a 300 anyway as
I was sending it the *exact* filename, not a partial name that might
match several files.

One theory I had which you hinted at here:
You aren't alone on this one:
http://thread.gmane.org/gmane.org.w3c.validator/3520
In that thread they indicate the problem is related to
"Accept-Language: *", so maybe that's what the W3C Validator sends?
If the validator sends an accept type of text/html, the server may try
to find files that match that but perhaps its PHP setting isn't correct,
so it applies MultiViews and tries to find a .html file instead of a
..php file. That would explain why my index file only works if I specify
index.html not index.php because of the default index property, and why
the internal church.php page gets a 404 because there is no match for
church.html. But it doesn't seem *quite* right.
Then again, I just tried something, and it's working now,
so you must have changed something?

See above. I can't imagine what I've done affected anything as it's
back to what it was before.

But I'm not complaining! It's just annoying that I don't know the
reason for it.

--
Chris Simon
os******@slcszetnet.co.uk
http://www.users.zetnet.co.uk/csimon/

** Get rid of all SLCs to reply directly **

[Chris Simon]

....anyway, this problem has brought out one good thing - I've found this
newsgroup! I went to the Validator's feedback page for help and it said
to try this group, so this has been my first post here. I think I'll
stick around...

--
Chris Simon
os******@slcszetnet.co.uk
http://www.users.zetnet.co.uk/csimon/

** Get rid of all SLCs to reply directly **

[Brian]

Chris Simon wrote:

Dave Patton wrote:

If I look at the HTTP headers, via the LiveHTTPHeaders Firefox
extension, or via: http://www.delorie.com/web/headers.html I don't
see the 300 response from your server, so I'd guess it's dependant
on the HTTP headers sent by the W3C validator.

Well, I've been playing around in the last hour or so with my web
hosting control panel, and it has a setting for indexes, i.e.
whether the server should return a list of files in a directory if
there is no index file. I turned them off, but found that broke the
site for some reason. I turned them back on again, and now I find
that it all works. I'm completely baffled. Perhaps it's now working,
so in fact it's not sending a 300 any more so you're not seeing that
now.

It appears that there something set on your server that you don't need
and that's causing problems in some cases. I should be able to tell you
to go to tech support at your hosting company, but chances are the
people working there know as much as you do. What's worse, they
generally act like they know quite a lot. Ignorant and cocky is a
dangerous combination.
As far as I can see, the server shouldn't have returned a 300 anyway
as I was sending it the *exact* filename, not a partial name that
might match several files.
This has been coming up an awful lot recently in the ciwa* groups. NB:
There is no filename on the client end. There is only a url that was
requested, and a response from the server, typically a document, but in
this case an error message.
If the validator sends an accept type of text/html, the server may
try to find files that match

Right. File names and extensions do matter on the server, as they are
often used to determine the response. As I said, you should be able to
go to support, but that is likely pointless. The alternative is to learn
about http and server stuff on your own, in other words, learn to do the
job of tech support yourself.

--
Brian (remove "invalid" to email me)