Doc #62074 [Com]: problematic header fields in example

Edit report at https://bugs.php.net/bug.php?id=62074&edit=1 ID: 62074 Comment by: phpmpan at mpan dot pl Reported by: julian dot reschke at gmx dot de Summary: problematic header fields in example Status: Open Type: Documentation Problem Package: Documentation problem PHP Version: Irrelevant Block user comment: N Private report: N New Comment: IANA is only storing a list of registered names. This: 1. Prevents software producers from using colliding names for different things. 2. Servers as a reference to find field definitions. This list is neither complete nor closed. 3864 describes the purpose of this document. Anyway, I think we should wait for someone, who knows rationale behind the headers in this example. I've never said server doesn't know real data type when sending "application/octet-stream". It would be plain stupid to send "application/octet-stream" for an unknown type. This is what the quoted fragment says and I agree with this. But I've said something completly different. It was about avoiding MIME sniffing on client side. I don't know what was the reason to put "Content-Transfer-Encoding" in this example, but you can find this in 1/3 of examples on the web (not only for PHP). So either this is a dirty hack to solve a browser bug or just another example of cargo cult programming, like infamous "srand(static_cast<int>(time(NULL)))" in C++. > The problem with Content-Disposition in the example is that > it doesn't work for many characters. Yes, I know. And I have nothing against this case. I've just forget to edit a sentence. Previous Comments: ------------------------------------------------------------------------ [2012-05-21 08:53:19] julian dot reschke at gmx dot de > HTTP is based on MIME and therefore inherits everything that is in MIME except things that are > explicitly excluded by 19.4 or - by a > common sense - have no use in HTTP context. Not true. There's a reason why the IANA header field registry distinguishes between MIME header fields and HTTP header fields. > > It's a valid media type, but sending it doesn't help anybody > Can you provide a reference to any _official_ standard or recommendation that confirms that? > "application/octet-stream" is used to > prevent clients from guessing content type. But if the server doesn't know the content type, then the client making a guess is strictly better than sending "application/octet-stream". See <http://www.w3.org/2001/tag/doc/mime-respect.html#reducing-inconsistency>: "Server managers (webmasters) SHOULD NOT specify an arbitrary Internet media type (e.g., "text/plain" or "application/octet-stream") when the media type is unknown." > I agree that "Content-Transfer-Encoding" was excluded from HTTP. You're right > here. However I believe that placing it in the example was > not a mistake. I think it's an old hack to get around a bug in some browser (IE?). It > should be removed if it's no longer neccessary. It's not necessary, and I doubt it ever was. > The "application/octet-stream" type. Initially I wanted to write about > "Content-Disposition" too until I realized you're talking about a > different issue in this case. I've just forget to edit it later. Ack. The problem with Content-Disposition in the example is that it doesn't work for many characters. ------------------------------------------------------------------------ [2012-05-21 08:39:25] phpmpan at mpan dot pl HTTP is based on MIME and therefore inherits everything that is in MIME except things that are explicitly excluded by 19.4 or - by a common sense - have no use in HTTP context. > It's a valid media type, but sending it doesn't help anybody Can you provide a reference to any _official_ standard or recommendation that confirms that? "application/octet-stream" is used to prevent clients from guessing content type. I agree that "Content-Transfer-Encoding" was excluded from HTTP. You're right here. However I believe that placing it in the example was not a mistake. I think it's an old hack to get around a bug in some browser (IE?). It should be removed if it's no longer neccessary. > Not sure what cases you are referring to here. See above. The "application/octet-stream" type. Initially I wanted to write about "Content-Disposition" too until I realized you're talking about a different issue in this case. I've just forget to edit it later. ------------------------------------------------------------------------ [2012-05-21 08:02:06] julian dot reschke at gmx dot de > > header('Content-Description: File Transfer'); > > This header field does not exist in HTTP. > It does. See 2045 8. That is MIME. MIME is not HTTP. See <http://www.iana.org/assignments/message-headers/perm-headers.html>. > > header('Content-Type: application/octet-stream'); > > This header field should either be set to the actual > > media type, or not set at all. > This is actual media type and it's perfectly valid content type identifier registered by > IANA. See 2046 4.5.1. It's a valid media type, but sending it doesn't help anybody. If you don't know the media type (and this seems to apply to the sample code), it is much better not to send it at all. > > header('Content-Transfer-Encoding: binary'); > > This header field does not exist in HTTP. > It does. See 2045 6.1. That is MIME. MIME is not HTTP. See RFC 2616, Section 19.4.5 (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.19.4.5>) and <http://www.iana.org/assignments/message-headers/perm-headers.html>. > At least the last two cases are also a /de facto/ industry standard, both are widely accepted. Not sure what cases you are referring to here. See above. ------------------------------------------------------------------------ [2012-05-21 07:32:46] phpmpan at mpan dot pl > header('Content-Description: File Transfer'); > This header field does not exist in HTTP. It does. See 2045 8. > header('Content-Type: application/octet-stream'); > This header field should either be set to the actual > media type, or not set at all. This is actual media type and it's perfectly valid content type identifier registered by IANA. See 2046 4.5.1. > header('Content-Transfer-Encoding: binary'); > This header field does not exist in HTTP. It does. See 2045 6.1. At least the last two cases are also a /de facto/ industry standard, both are widely accepted. ------------------------------------------------------------------------ [2012-05-20 07:48:44] julian dot reschke at gmx dot de Description: ------------ --- From manual page: http://www.php.net/function.readfile#refsect1- function.readfile-examples --- header('Content-Description: File Transfer'); This header field does not exist in HTTP. header('Content-Type: application/octet-stream'); This header field should either be set to the actual media type, or not set at all. header('Content-Disposition: attachment; filename='.basename($file)); This code will break if the filename contains non-token characters, such as ",", ";" or non-ASCII characters. See RFC 6266. header('Content-Transfer-Encoding: binary'); This header field does not exist in HTTP. header('Expires: 0'); header('Cache-Control: must-revalidate'); header('Pragma: public'); header('Content-Length: ' . filesize($file)); ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=62074&edit=1