SAPI should not add charset to each text subtype

[Yurunsoft]

Description

The built-in webserver will add ";charset=UTF-8" to the end of the Content-Type response header of the SSE response

The following code:

<?php
header('Content-Type: text/event-stream');
for ($i = 0; $i < 3; ++$i) {
    echo 'data: ' . $i . "\n\n";
}

Run server:

php -S 127.0.0.1:8080 test.php

Test:

curl http://127.0.0.1:8080/ -vvv

Resulted in this output:

# curl http://127.0.0.1:8080/ -vvv
*   Trying 127.0.0.1:8080...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Host: 127.0.0.1:8080
< Date: Fri, 28 Apr 2023 02:51:28 GMT
< Connection: close
< X-Powered-By: PHP/8.1.18
< Content-type: text/event-stream;charset=UTF-8
<
data: 0

data: 1

data: 2

* Closing connection 0

But I expected this output instead:

# curl http://127.0.0.1:8080/ -vvv
*   Trying 127.0.0.1:8080...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Host: 127.0.0.1:8080
< Date: Fri, 28 Apr 2023 02:51:28 GMT
< Connection: close
< X-Powered-By: PHP/8.1.18
< Content-type: text/event-stream
<
data: 0

data: 1

data: 2

* Closing connection 0

PHP Version

PHP 8.0.28, 8.1.18, 8.2.5

Operating System

No response

[bukka]

I think this is sort of valid when we consider the latest MIME RFC 6838: https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1

As specified in [RFC6657], a "charset" parameter SHOULD NOT be
specified when charset information is transported inside the payload
(e.g., as in "text/xml").

As you can see it is still SHOULD NOT so not a complete requirement but I think we should change it.

That said I'm not sure this is actually a bug but more the fact that PHP follows what's in RFC 4288: https://datatracker.ietf.org/doc/html/rfc4288#section-4.2.1

The "text" media type is intended for sending material that is
principally textual in form. A "charset" parameter MAY be used to
indicate the charset of the body text for "text" subtypes, notably
including the subtype "text/plain", which is a generic subtype for
plain text defined in [RFC2046]

This allows using charset for any text subtypes. It means we should probably just treat this as a feature request and target master only. Also this does not impact only text/event-stream but also other subtypes with given charset (e.g. text/xml).

[Yurunsoft]

Sorry, I seem to have made a mistake

[bukka]

@Yurunsoft It is fine to leave it open as I think we should change it - it just needs to be reclassified as a feature request.

[Yurunsoft]

I missed ob_flush() before and it didn't do what I wanted it to do. Now he works.

<?php
header('Content-Type: text/event-stream');
for ($i = 0; $i < 3; ++$i) {
    echo 'data: ' . $i . "\n\n";
    ob_flush();
    sleep(1);
}

[bukka]

Well this

<?php
header('Content-Type: text/event-stream');
for ($i = 0; $i < 3; ++$i) {
    echo 'data: ' . $i . "\n\n";
}

should still not produce charset so I think your report is valid.