improve headers_list() example

[hakre]

Two things with the PHP example code:

1. X- prefix header names June 2012 1, 2.

2. PHP prepends the default_charset 3 on any text/* media type in Content-Type header (unless the charset is with the header() call. The example code output now has it (with the UTF-8 default).

[tiffany-taylor]

These lines

doc-en/reference/network/functions/headers-list.xml

Lines 63 to 64 in 029df69

	[0]=>
	string(23) "X-Powered-By: PHP/5.1.3"

could probably be removed and

doc-en/reference/network/functions/headers-list.xml

Line 65 in 029df69

[1]=>

updated to [0].

[salathe]

Thanks @hakre !

Added a few details that need to be fixed, as suggested changes.

Other things to consider changing, though not required:

• Change &example.outputs; to &examples.outputs.similar; (i.e. to say The above examples will output something similar to: ) since the output may vary by PHP version, configuration, SAPI (?), etc. These XML entities, and many others, can be found in the language-snippets.ent file in the top-level directory of the repo.
• Update, or remove for simplicity, the X-Powered-By header. PHP 5.1.3 is pretty ancient. Edit: it looks like you updated the version number while I was typing this. :)

[hakre]

There seems to be some non-signigifcant whitespace issue as well, I'll add it.

[kamil-tekiela]

I think I preferred your first version where you added charset. The header produced by PHP is nonconformant from what I see.

[hakre]

I think I preferred your first version where you added charset. The header produced by PHP is nonconformant from what I see.

Not sure I get what you mean. The header produced by PHP looks fine, doesn't it?:

Content-type: text/plain;charset=UTF-8

HTTP Header name fine, mime media type fine, charset attribute fine. not? @kamil-tekiela

[kamil-tekiela]

When you specify the charset explicitely then PHP will produce the header exactly as specified:

Content-Type: text/html; charset=UTF-8

When you omit the charset, PHP will lowercase type and remove space before ;:

Content-type: text/html;charset=UTF-8

The example given by MDN is

Content-Type: text/html; charset=UTF-8

[hakre]

@kamil-tekiela: The whitespace is optional (OWS - optional white space)

RFC 7231 Section 3.1.1.1 says:

media-type = type "/" subtype *( OWS ";" OWS parameter )

and gives the following examples for media types in the Content-Type header:

     text/html;charset=utf-8
     text/html;charset=UTF-8
     Text/HTML;Charset="utf-8"
     text/html; charset="utf-8"

The second and the last one come close to the one on MDN but actually the example on MDN is not in there.. I'd say it is another valid example.

[kamil-tekiela]

Thanks for pointing to the spec. I am aware the spaces are optional and the type, subtype and parameter are case-insensitive. I am not sure about the header name, but as I see user agents treat it in case insensitive way.

My point is that when we document the output header, it would be safer to use the variant where PHP doesn't change the case or white space. What if we decide to change the Content-type to Content-Type in a future PHP release? If it's possible to document in such a way that we can be sure of what the output is without relying on the way PHP prepares it internally, or some INI directive, then I think that would be preferable.

[hakre]

My point is that when we document the output header, it would be safer to use the variant where PHP doesn't change the case or white space. What if we decide to change the Content-type to Content-Type in a future PHP release?

Well it's docs and the example output is taken from the PHP version as in the X-Powered-By header. No decision for changes in src from my end, the examples should not imply anything regarding that from my perspective.

Similar to the optional white space, case does not matter here (the header names are equivalent, similar to the token and quoted token in the media type). For the header names that is in the HTTP specs, MDN should have it as well as IETF.

• RFC 7230 3.2. Header Fields

Therefore I don't see an issue with that. Also &examples.outputs.similar; has been edited in.

Additional ref regarding case-sensitivity: RFC 4790 9.2.1. ASCII Casemap Collation Description (non-locale-aware, Posix "C" locale like)

But perhaps too technical for a docs discussion maybe @kamil-tekiela

[kamil-tekiela]

Sorry, maybe my language skills are at fault here. I am not questioning the RFC or why PHP outputs the header the way it does. All I am saying is that it's a little confusing for readers of the PHP manual to see that you are sending Content-Type but the output example says Content-type. This could be easily avoided if you send the header in full with the charset. This way, the case in the example's code and the example's output will match. Also, specifying the charset in the header in code, will not leave readers wondering where the charset came from.

I am not sure how the discussion became technical; I did not mean to make it technical. All I said is that the example looked better when you had:

/* Specify plain text content in our response */
header('Content-Type: text/plain; charset=UTF-8');

The output will then be exactly what you provided to the header() function.
If I am still not making sense you can ping me in chat in room 11, maybe I will be able to explain it better.

[hakre]

Modified to Content-Type: text/plain; charset=UTF-8.

[kamil-tekiela]

Thanks. Other than this one small change it looks good.

[kamil-tekiela]

Thank you. I merged it now.