> 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.

> > 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.

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.

> 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.

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.

> 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.

The list is "complete" in that it contains all registered header field names. Of course it's not "complete" with respect to real-world use, because people use unregistered header fields all the time. And yes, it's not closed.

My point was that the registry distinguishes between MIME and HTTP header fields. So no, just because something is defined in RFC 2045 doesn't make it an HTTP header field as well. 

> 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.

The example code currently unconditionally sends "application/octet-stream". Do we agree that this is not something people should do?

> 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++.

I don't know where this comes from, but I opened this bug because I suspect that this example is part of the problem. I see the header in examples a lot on stackoverflow, any a large percentage are PHP examples.

And yes, I can confirm that the header field has not been needed in any browser I have checked since ~2003. (And yes, I have written code that serves files-for-download as well).

So what's the reason for not fixing this?

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

The example functions as intended, this is the reason it has not been fixed - it 
is not broken.
Examples found in documentation are intended to illustrate use, and that is all. 
They are not required to document best use, only use.
As always, it is up to the programmer to determine the best use of software.