HTTP header Content-Type without charset in PHP 5.6 about http HOT 26 CLOSED

I don't think Nette should "fix" this.
2nd parameter sounds good, but is unfortunately a BC break.

from http.

it could bring some problems in some cases (back compatibility for example)

1. Changing Content-Type header from e.g. text/html to text/html; charset=utf-8 is not a BC break (if you are using utf-8).
2. This has been added to PHP 5.6 to improve security. I don't think we should intentionally disable this security improvement unless good reasons are found.
3. Regardless of the outcome we should add tests to cover whatever behavior Nette choose.

On the other hand it is quite stupid that you can not simply set the Content-Type header to whatever you want.

If good reasons are found, I would go for:

    public function setContentType($type, $charset = NULL)
    {
        if (PHP_VERSION_ID >= 50600 && $charset === NULL && func_num_args() >= 2) {
            $defaultCharset = ini_get('default_charset');
            ini_set('default_charset', NULL);
        }

        $this->setHeader('Content-Type', $type . ($charset ? '; charset=' . $charset : ''));

        if (isset($defaultCharset)) {
            ini_set('default_charset', $defaultCharset);
        }

        return $this;
    }

from http.

@Majkl578 The second (optional) parameter is already there.

@JanTvrdik I understand there are some reasons why PHP changed it. However if you are using some embedded device which is simple and stupid then it the communication between your server and the device can be broken. For example the device compares Content-Type header as it is. Then text/plain;charset=utf-8 is not the same as text/plain.

If I would like to use charset in the header then I would add it there by myself. Your code snippet is what I have been thinking about :-) It forces empty charset in the way I would expect it.

from http.

Fixing broken HTTP implementation in embedded device is too narrow use case for justifying the change in Nette, because you can easily work around this in your application which deals which this specific device. If it breaks something more important we may reconsider it.

from http.

An embedded device is just an example. It can by something else (mobile app, external system, ...) which is not under your control and can depend on your response headers. It is usually easier to use header content as it is instead of parsing it. Especially when it sends you simple Content-Type without charset. I know it is not good behavior but it could bring a lot of problems in production. And it is definitely easier to add NULL as second argument to used method instead of copy and paste the same code on all affected places.

from http.

It is not in our interest to support those who do not respect standards (HTTP in this case). We do it only when we are forced to do so.

from http.

@JanTvrdik however, I don't think the PHP should modify the header I'm sending in such a way. If I put there something, I've probably had a reason for it to be in such format and if not I'm and idiot and deserve the consequences.

I see no reason NOT to fix it.

from http.

BTW: This PHP feature (adding charset to Content-Type header) has been in PHP for ages. They just changed default charset from "" to "UTF-8" in PHP 5.6

from http.

Interesting, but I still consider it "magic" and really unwanted.

from http.

@fprochazka You consider security really unwanted? Why? In real world – this is wanted, except for some crazy edge cases such as embedded devices not respecting HTTP.

from http.

@stekycz Are you solving real problem with real use case, or is it chat?

from http.

@dg I have solved real problem in one project. However I was not sure if it is too edge case or if it is a bug. That is the reason why I have opened this issue.

from http.

@JanTvrdik You can have default value as utf-8 for the setContentType method, the final api is a detail at this point. All I'm saying is that I expect to send this header Content-Type: text/plain (and the fact that it's a Content-Type is also a detail) but charset is automagically added.

It's unneccesary magic => bad. There should be some kind of warnings and a lot of education instead. You can't say it's not magic, that I send one string and the PHP goes and changes it to another.

from http.

Because HTTP specification says that media-type does not have to use any parameter then I assume this magic is a bug. Then it could by solved for all PHP versions whose are affected.

from http.

The default_charset is like a cancer, since 5.6 it is everywhere: htmlspecialchars, html_entity_decode, etc. Now you have to always call htmlspecialchars with 3rd argument, because otherwise function is not deterministic :-(

The proposed solution setContentType($type, NULL) is magic, usable only for a few people who know what's going on.

I thought about it for a long time and my suggestion is: let it be.

(but it can be mentioned in phpDoc)

from http.

@dg Hmm, a lot of changes I can see. I could prepare gist instead of this pull. The gist could be mentioned in Nette doc. What about that?

from http.

Notice like PHP in some cases appends ini_get('default_charset') is enough, isn't?

from http.

I guess...

from http.

Now you have to always call htmlspecialchars with 3rd argument

Why? We can make a strict requirement that Nette requires default_charset to be set to UTF-8. Why would that be a problem?

from http.

I am not talking about Nette, but about fundamentally bad decision.

from http.

So you think that the previous state (some functions depending on one ini setting, some functions depending on entirely different ini setting, some functions with a default value independent of ini settings) was better?

from http.

Yes previous state was definitely better. (And I don't know what are you talking about, see changelog http://php.net/htmlspecialchars#refsect1-function.htmlspecialchars-changelog or http://php.net/manual/en/function.html-entity-decode.php#refsect1-function.html-entity-decode-changelog).

from http.

Previously PHP behavior was affected by the following ini settings:

php.input_encoding
php.internal_encoding
php.output_encoding
iconv.input_encoding (Default: php.input_encoding)
iconv.internal_encoding (Default: php.internal_encoding)
iconv.output_encoding (Default: php.output_encoding)
mbstring.http_input (Default: php.input_encoding)
mbstring.internal_encoding (Default: php.internal_encoding)
mbstring.http_output (Default: php.output_encoding)

Since PHP 7 (PHP 5.6 only deprecated the previous settings) there will be only one ini setting – default_charset. You need to set this properly and you are good to go. It's simple and consistent. Removing the settings entirely is not possible due to BC.

from http.

Why are you talking about it? How it relates to this thread? How it relates to my comment?

from http.

No good reasons, really. I was just a bit surprised that you consider the previous state better.

from http.

Because I don't like global variables. Thats all. I had to use last parameter in all iconv_* and mb_* and http_build_query functions before, now I have to do it for htmlspecialchars and other functions. Is it better? Absolutely no.

from http.