-
Notifications
You must be signed in to change notification settings - Fork 152
UTF-8 URIs are broken by parse_url when locale is set #354
Comments
…se fail with some debug information zendframework#354
As mentioned in the comments on the PHP bug which I linked, this issue seems to be platform specific (as well as depending on what locale is set). After quite a bit of trying, I've so far been unable to write any unit test for this which fails on Travis, and I'm now running out of ideas. I can at least say for sure that this is definitely reproducible on MacOS, and have had other people around the office run the tests on their Mac machines and see the same failures. |
@Pudge601 Can you then provide the test which is failing on MacOS? I'll check on mine and maybe will have some ideas... |
I've committed them on the issue/354-add-failing-tests branch of my fork of this repo. |
@Pudge601 I am getting errors on MacOS as you said. What if we update Travis to run tests on different environments? See: https://docs.travis-ci.com/user/multi-os/ I see you've suggested some solutions, so we can resolve it. But not sure if it is worth to do it, if the problem is only on MacOS... |
Yeah, I looked at the same thing, but found this page in the Travis docs which states that;
😞 |
This repository has been closed and moved to laminas/laminas-diactoros; a new issue has been opened at laminas/laminas-diactoros#9. |
The
parse_url
function is not multibyte safe, and was never designed to be, which seems to be why this bug from 2010 has still not been addressed. As mentioned in the comments on that bug, a nicer behaviour would be forparse_url
to "treat all extended characters ... as opaque characters and copy them as-is without modification", but I don't see that happening any time soon.There are a couple of options I can think of to try and support UTF8 URIs in this library;
parse_url
which URL encodes/decodes extended characters (e.g. in this comment from the manual page)parse_url
Or alternatively this library could simply reject URI's with extended characters which aren't properly encoded, as they are technically invalid according to RFC 3986.
Whichever way, it might be worth adding something to the Travis config to run the tests under different locale environments to show how this is reproduced in the unit tests (though this might be a pain, since the available values for the locale are platform dependent).
Originally posted by @Pudge601 in #155 (comment)
The text was updated successfully, but these errors were encountered: