Last modified: 2013-03-11 21:01:02 UTC
I was using w3m (0.5.2) to access the http://wikitech.wikimedia.org/ page, and I get: Not Acceptable An appropriate representation of the requested resource /view/ Main_Page could not be found on this server. Available variants: • view.php , type application/x-httpd-php ───────────────────────────────────────────────────────────────────── Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.7 with Suhosin-Patch mod_ssl /2.2.8 OpenSSL/0.9.8g Server at wikitech.wikimedia.org Port 80 HTTP Request: 0x0030: 6b 4745 5420 2f76 6965 772f 4d61 GET./view/Ma 0x0040: 696e 5f50 6167 6520 4854 5450 2f31 2e30 in_Page.HTTP/1.0 0x0050: 0d0a 5573 6572 2d41 6765 6e74 3a20 7733 ..User-Agent:.w3 0x0060: 6d2f 302e 352e 320d 0a41 6363 6570 743a m/0.5.2..Accept: 0x0070: 2074 6578 742f 6874 6d6c 2c20 7465 7874 .text/html,.text 0x0080: 2f2a 3b71 3d30 2e35 2c20 696d 6167 652f /*;q=0.5,.image/ 0x0090: 2a0d 0a41 6363 6570 742d 456e 636f 6469 *..Accept-Encodi 0x00a0: 6e67 3a20 677a 6970 2c20 636f 6d70 7265 ng:.gzip,.compre 0x00b0: 7373 2c20 627a 6970 2c20 627a 6970 322c ss,.bzip,.bzip2, 0x00c0: 2064 6566 6c61 7465 0d0a 4163 6365 7074 .deflate..Accept 0x00d0: 2d4c 616e 6775 6167 653a 2065 6e3b 713d -Language:.en;q= 0x00e0: 312e 300d 0a48 6f73 743a 2077 696b 6974 1.0..Host:.wikit 0x00f0: 6563 682e 7769 6b69 6d65 6469 612e 6f72 ech.wikimedia.or 0x0100: 670d 0a0d 0a g.... HTTP Response: 0x0030: 4854 5450 2f31 2e31 2034 3036 HTTP/1.1.406 0x0040: 204e 6f74 2041 6363 6570 7461 626c 650d .Not.Acceptable. 0x0050: 0a44 6174 653a 2054 7565 2c20 3234 204e .Date:.Tue,.24.N 0x0060: 6f76 2032 3030 3920 3030 3a33 323a 3138 ov.2009.00:32:18 0x0070: 2047 4d54 0d0a 5365 7276 6572 3a20 4170 .GMT..Server:.Ap 0x0080: 6163 6865 2f32 2e32 2e38 2028 5562 756e ache/2.2.8.(Ubun 0x0090: 7475 2920 5048 502f 352e 322e 342d 3275 tu).PHP/5.2.4-2u 0x00a0: 6275 6e74 7535 2e37 2077 6974 6820 5375 buntu5.7.with.Su 0x00b0: 686f 7369 6e2d 5061 7463 6820 6d6f 645f hosin-Patch.mod_ 0x00c0: 7373 6c2f 322e 322e 3820 4f70 656e 5353 ssl/2.2.8.OpenSS 0x00d0: 4c2f 302e 392e 3867 0d0a 416c 7465 726e L/0.9.8g..Altern 0x00e0: 6174 6573 3a20 7b22 7669 6577 2e70 6870 ates:.{"view.php 0x00f0: 2220 3120 7b74 7970 6520 6170 706c 6963 ".1.{type.applic 0x0100: 6174 696f 6e2f 782d 6874 7470 642d 7068 ation/x-httpd-ph 0x0110: 707d 207b 6c65 6e67 7468 2036 357d 7d0d p}.{length.65}}. 0x0120: 0a43 6f6e 7465 6e74 2d4c 656e 6774 683a .Content-Length: 0x0130: 2035 3234 0d0a 436f 6e6e 6563 7469 6f6e .524..Connection 0x0140: 3a20 636c 6f73 650d 0a43 6f6e 7465 6e74 :.close..Content 0x0150: 2d54 7970 653a 2074 6578 742f 6874 6d6c -Type:.text/html 0x0160: 3b20 6368 6172 7365 743d 6973 6f2d 3838 ;.charset=iso-88 0x0170: 3539 2d31 0d0a 0d0a 3c21 444f 4354 5950 59-1....<!DOCTYP 0x0180: 4520 4854 4d4c 2050 5542 4c49 4320 222d E.HTML.PUBLIC."- 0x0190: 2f2f 4945 5446 2f2f 4454 4420 4854 4d4c //IETF//DTD.HTML 0x01a0: 2032 2e30 2f2f 454e 223e 0a3c 6874 6d6c .2.0//EN">.<html 0x01b0: 3e3c 6865 6164 3e0a 3c74 6974 6c65 3e34 ><head>.<title>4 0x01c0: 3036 204e 6f74 2041 6363 6570 7461 626c 06.Not.Acceptabl 0x01d0: 653c 2f74 6974 6c65 3e0a 3c2f 6865 6164 e</title>.</head 0x01e0: 3e3c 626f 6479 3e0a 3c68 313e 4e6f 7420 ><body>.<h1>Not. 0x01f0: 4163 6365 7074 6162 6c65 3c2f 6831 3e0a Acceptable</h1>. Good to watch out when implementing bug 16659 and bug 17981. Does not seem to be a MediaWiki problem, since https://wiki.toolserver.org/ works fine with w3m. Changing skin with ?useskin does not help. Apache content negotiation problem?
I tried reproducing it with curl : curl -v -H "User-Agent: w3m/0.5.2" \ -H "Accept: text/html, text /*; q=0.5, image/*" \ -H "Accept-Encoding: gzip, compress, bzip, bzip2, deflate" \ -H "Accept-Language: en; q=1.0" \ http://wikitech.wikimedia.org/ wikitech returns a 301 with content type set to text/html * About to connect() to wikitech.wikimedia.org port 80 (#0) * Trying 207.192.72.124... connected * Connected to wikitech.wikimedia.org (207.192.72.124) port 80 (#0) > GET / HTTP/1.1 > Host: wikitech.wikimedia.org > User-Agent: w3m/0.5.2 > Accept: text/html, text /*; q=0.5, image/* > Accept-Encoding: gzip, compress, bzip, bzip2, deflate > Accept-Language: en; q=1.0 > < HTTP/1.1 301 Moved Permanently < Date: Sat, 22 Jan 2011 13:32:35 GMT < Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.7 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g < X-Powered-By: PHP/5.2.4-2ubuntu5.7 < Vary: Accept-Encoding,Cookie < Expires: Thu, 01 Jan 1970 00:00:00 GMT < Cache-Control: private, must-revalidate, max-age=0 < Last-Modified: Sat, 22 Jan 2011 13:32:35 GMT < Location: http://wikitech.wikimedia.org/view/Main_Page < Content-Encoding: gzip < Content-Length: 26 < Content-Type: text/html; charset=utf-8 < * Connection #0 to host wikitech.wikimedia.org left intact * Closing connection #0 I am closing this bug as working for me probably following a change on our side.
1) Well, the problem happens when w3m (or any other browser) follows this very redirect. I have updated the URL on this bug to reflect this. Sorry, I wasn't specific enough. 2) You have a space after "text" before "/*". If this is changed, the bug is easily reproduced with curl as well (I have added option to avoid proxies): curl -v -H "User-Agent: w3m/0.5.2" --noproxy "*" \ -H "Accept: text/html, text/*; q=0.5, image/*" \ -H "Accept-Encoding: gzip, compress, bzip, bzip2, deflate" \ -H "Accept-Language: en; q=1.0" \ http://wikitech.wikimedia.org/view/Main_Page * About to connect() to wikitech.wikimedia.org port 80 (#0) * Trying 207.192.72.124... connected * Connected to wikitech.wikimedia.org (207.192.72.124) port 80 (#0) > GET /view/Main_Page HTTP/1.1 > Host: wikitech.wikimedia.org > User-Agent: w3m/0.5.2 > Accept: text/html, text/*; q=0.5, image/* > Accept-Encoding: gzip, compress, bzip, bzip2, deflate > Accept-Language: en; q=1.0 > < HTTP/1.1 406 Not Acceptable < Date: Sat, 22 Jan 2011 20:38:34 GMT < Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.7 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g < Alternates: {"view.php" 1 {type application/x-httpd-php} {length 65}} < Content-Length: 524 < Content-Type: text/html; charset=iso-8859-1 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>406 Not Acceptable</title> </head><body> <h1>Not Acceptable</h1> <p>An appropriate representation of the requested resource /view/Main_Page could not be found on this server.</p> Available variants: <ul> <li><a href="view.php">view.php</a> , type application/x-httpd-php</li> </ul> <hr> <address>Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.7 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at wikitech.wikimedia.org Port 80</address> </body></html> * Connection #0 to host wikitech.wikimedia.org left intact * Closing connection #0
The heading in question seem to be accept. If you have application/x-httpd-php in the list of acceptable mime types in the accept request header, all is good (Firefox has */* in that list, so its good). If you only have text/html in the accept header, then you get the 406 error. Sounds like apache is misconfigured somehow.
I can't reproduce the error with w3m 0.5.2: $ w3m http://wikitech.wikimedia.org/view/Main_Page works fine. (Fresh w3m install on Ubuntu 10.10 x86_64.) But I *can* reproduce it with your curl line. The problem is related to the 'Accept' header; Apache seems to be trying to negotiate as with the MultiViews option I think, so it's looking for "view".something and has only "view.php" available. When the user-agent claims to only support HTML, text formats, and image formats: curl -v -H "User-Agent: w3m/0.5.2" --noproxy "*" \ -H "Accept: text/html, text/*; q=0.5, image/*" \ http://wikitech.wikimedia.org/view/Main_Page You get a failure since "view.php"'s *file* type is none of those: Alternates: {"view.php" 1 {type application/x-httpd-php} {length 65}} On the other hand if we include */* on the end, it works: curl -v -H "User-Agent: w3m/0.5.2" --noproxy "*" \ -H "Accept: text/html, text/*; q=0.5, image/*; q=0.25, */*" \ http://wikitech.wikimedia.org/view/Main_Page Proper fix is probably to use Alias entries to map "view" to "view.php" etc; these won't be dependent on type negotiation from the Accept headers. This'd also allow turning off Options MultiViews if desired, for safety or consistency.
Note -- I don't get the same failures in w3m because my w3m emits a more inclusive Accept header: Accept: text/html, text/*;q=0.5, image/*, application/*, multipart/*, audio/* The application/* part catches the PHP script in content negotiation.
Looks like Accept: text/html alone Accept: text/* alone Accept: text/html, text/* give 406 Accept: application/* gives the desired output (gzipped HTML). index.php?title=Main_Page does not exhibit this problem, so it must be related to the way the PHP handler is determined for the $wgActionPath pretty URLs. Here's some discussion: http://ilia.ws/archives/226-Beware-of-the-default-Apache-2-config-for-PHP.html http://www.ush.it/2008/07/02/mod_negotiation-directory-listing-filename-bruteforcing/ Looks like using "SetHandler application/x-httpd-php" is a better replacement of "AddHandler" or "AddType" in the apache configuration file. Seems to be an apache problem, since Oracle-iPlanet-Web-Server/7.0 running on wiki.toolserver.org does not exhibit the problem.
Removing "shell" keyword for things that aren't directly doable by shell users etc
Adding ops keyword
Removing shell keyword if exists
Still there as of 2012-03-10
This is unlikely to have carried over from the old wikitech to labsconsole (the new wikitech). Marking WORKSFORME but please test and report the current state.
Yes, I could access the site with w3m and even log in and edit. Thank you.
