php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13421 Problematic MIME-Type "application/x-httpd-php"
Submitted: 2001-09-24 17:53 UTC Modified: 2002-10-16 01:00 UTC
Votes:320
Avg. Score:3.4 ± 0.9
Reproduced:88 of 125 (70.4%)
Same Version:36 (40.9%)
Same OS:44 (50.0%)
From: php at matthias-wimmer dot de Assigned:
Status: No Feedback Package: Apache related
PHP Version: 4.0.6 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: php at matthias-wimmer dot de
New email:
PHP Version: OS:

 

 [2001-09-24 17:53 UTC] php at matthias-wimmer dot de
I noticed that using the MIME-Type "application/x-httpd-php" for php-Scripts produces a problem under Apache 1.3.x with MultiViews turned on.
When an user agent (like Google or Altavista) sends the Header "Accept: text/*" and the complete location is not given (e.g. "http://domain.com/index" instead of "http://domain.com/index.php") Apache tries to guess the right file-name extension. But Apache will answer the request with a 406 error ("not acceptable") becaus it thinks the php file is of type "application/x-httpd-php", which is not compatible to "text/*".
Me suggested solution would be to change the MIME-Type to "text/x-httpd-php". Content negotiation under Apache 1.3 would work then.

Note: This problem is non existend at Apache 2.0.x where I can change the MIME type without any problems because php is a filter there.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-08 16:40 UTC] hholzgra@php.net
thats something you have to deal with at the application level IMHO

PHP cannot do much about it as it does not deal with static content like apache does, so it makes no sense to run a script first and discard the results later just because the do not match the accept types 

a client sending accept headers should be clever enogh to deal with unexpected return types so no harm should be taken by this
 [2002-08-09 05:39 UTC] hholzgra@php.net
sorry, mixed up two bugs here, reopening
 [2002-09-30 20:48 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-10-16 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2002-12-23 16:03 UTC] j dot westendorp at chello dot nl
I have the same problem: I can't view my "Multiviewed" pages (e.g. http://domain.com/news/38 instead of http://domain.com/news.php?ID=38 ) with a user agent that does not send the "Accept: */*" request header (like AvantGo 3.2 does) because Apache throws a "406 No Acceptable Variant" error.

I'm running PHP 4.2.2 on Apache 1.3.19 (Red-Hat/Linux)
 [2003-03-14 06:15 UTC] bartek at luka dot dagma dot pl
It seems like the same problem occurs in 4.3.1 version of PHP running on Apache 1.3.x.
 [2008-12-11 18:51 UTC] JAMALMNK at HOTMAIL dot COM
JAMAL
 [2009-02-04 21:55 UTC] akms_77 at hotmail dot com
Kqcs
 [2009-03-30 21:02 UTC] earthmagik at sbcglobal dot net
What the H*** is the problem??? I have never had this before, and do not wantit again!!!
 [2009-06-05 06:54 UTC] NADIMHANA at HOTMAIL dot COM
RONALDO
 [2013-11-12 03:25 UTC] php dot net at phor dot net
Still an issue in 2013. 

http://stackoverflow.com/questions/19169337/apache-2-multiviews-and-406-error-for-image-request

Also, please note, PHP is capable to respond to ANY mime type. I have a PHP script that wants to reply with images and sounds. Clients are not requesting with Accept: image/* which also results in a 406.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 30 17:01:29 2024 UTC