Re: php6: input encoding, filter and making JIT really JIT

On Dec 14, 2006, at 12:59 PM, Pierre wrote:

The main disadvantages are: - the lack of flexibility, encoding must be set before the script gets the hand, using vhost config or htaccess - the possible bad encoding detection will force the user to manually parse the raw request (when available).

Also: - no way to issue an error if conversion fails except by setting a flag that has to be retrieved with a function - much harder to get to _charset_ if it's at the end of the request

* Init - don't parse the request but simply store it for later processing

We can still parse the data, we just can't decode it. Parsing would populate arrays (internal or otherwise) with the binary data that can later be decoded and filtered in JIT fashion.

* Runtime - when a input variable is fetched: - encoding is defined using unicode.request_encoding

Or via _charset_, or provided by user, etc.

The main advantage of this solution is the absence of magic for the user. The encoding detection can be checked and/or set in time by the user before the input processing, it is safe and flexible.

And we can issue errors in consistent fashion.

There is no real technical disadvantages but requires more work and changes in the engine. But these changes will also bring some more performance improvements (if (0) $t = $_ENV['foo']; will not trigger jit).

I guess we need to know how hard it would be to implement runtime JIT for GET/POST/COOKIE registration. -Andrei