You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current implementation of binary mode (RequestFactory::setBinary()) is stupid and encourages insecure behavior, because I usually want to transfer only a single parameter in binary. To achieve that user should not disable UTF-8 validation on all input parameters.
We should either
remove the binary mode entirely or
improve it to support binary mode only for parameter with certain name.
Currently I'm in favor of the first option for the following reasons:
transporting binary data is rare
users can very easily just use $_GET['binaryData'] or $_POST['binaryData'] – its ugly but practical
users can implement wrapper around RequstFactory which would allow specifying that certain parameters should be treated as binary.
Note: If we choose the remove the binary mode entirely with the vision that users may implement custom wrapper around RequestFactory we may no longer throw exception (see #30 for related discussion) for invalid parameters.
My only contribution to this discussion would be stating that I've never needed to allow binary on RequestFactory, which is by itself not an argument for removing it :) I really have no idea what is it good for.
Now that I think about it, I usually transfer binary data using base64_encode.
I didn't know that, the name is confusing. What are the real-word use cases when you would enable binary mode? When designing an API for somebody who is not enable to send you UTF-8?
@dg What was there reason to remove support for other encodings. Binary only seems bit unsafe (everyone has to count with it while working with presenters and so on).
I'm wondering if there is a single Nette application that uses non-utf-8 encoding. Because for example you cannot use Latte with non-utf-8 encoding. There is not a single setBinary mention on forum.
@dg What is your decision – can I remove the binary mode entirely or do you think we should keep it and close therefore this issue?
Activity
fprochazka commentedon Dec 18, 2014
My only contribution to this discussion would be stating that I've never needed to allow binary on RequestFactory, which is by itself not an argument for removing it :) I really have no idea what is it good for.
Now that I think about it, I usually transfer binary data using
base64_encode.Ideal would be to find somebody who is using it.
dg commentedon Dec 18, 2014
Binary mode is not intended for transfering single parameter, it makes RequestFactory able to work with non-utf8 encodings.
JanTvrdik commentedon Dec 18, 2014
I didn't know that, the name is confusing. What are the real-word use cases when you would enable binary mode? When designing an API for somebody who is not enable to send you UTF-8?
dg commentedon Dec 18, 2014
Real-world use case is each web with non-utf8 encoding.
mishak87 commentedon Dec 18, 2014
@dg What was there reason to remove support for other encodings. Binary only seems bit unsafe (everyone has to count with it while working with presenters and so on).
dg commentedon Dec 18, 2014
Nette supports only utf-8 since 2.0. It doesn't prevent when you want to use other encoding, but either doesn't help you.
JanTvrdik commentedon Dec 18, 2014
I'm wondering if there is a single Nette application that uses non-utf-8 encoding. Because for example you cannot use Latte with non-utf-8 encoding. There is not a single
setBinarymention on forum.@dg What is your decision – can I remove the binary mode entirely or do you think we should keep it and close therefore this issue?
dg commentedon Dec 18, 2014
I think it can be removed in next big version, but now it is unnecessary BC break.
JanTvrdik commentedon Dec 18, 2014
Ok, closing for now. I'll put it on my list of things to do in Nette 3.
dg commentedon Dec 19, 2014
Why closing?
JanTvrdik commentedon Dec 19, 2014
Because it's won't fix for know because you have not yet opened a branch that can accept this change.