Skip to content

RequestFactory: remove or improve binary mode #34

Closed

Description

@JanTvrdik

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.

Thoughts? cc @dg, @fprochazka


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.

Activity

  1. fprochazka commented on Dec 18, 2014

    @fprochazka
    Contributor

    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.

  2. dg commented on Dec 18, 2014

    @dg
    Member

    Binary mode is not intended for transfering single parameter, it makes RequestFactory able to work with non-utf8 encodings.

  3. JanTvrdik commented on Dec 18, 2014

    @JanTvrdik
    ContributorAuthor

    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?

  4. dg commented on Dec 18, 2014

    @dg
    Member

    Real-world use case is each web with non-utf8 encoding.

  5. mishak87 commented on Dec 18, 2014

    @mishak87

    @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).

  6. dg commented on Dec 18, 2014

    @dg
    Member

    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.

  7. JanTvrdik commented on Dec 18, 2014

    @JanTvrdik
    ContributorAuthor

    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?

  8. dg commented on Dec 18, 2014

    @dg
    Member

    I think it can be removed in next big version, but now it is unnecessary BC break.

  9. JanTvrdik commented on Dec 18, 2014

    @JanTvrdik
    ContributorAuthor

    Ok, closing for now. I'll put it on my list of things to do in Nette 3.

  10. dg commented on Dec 19, 2014

    @dg
    Member

    Why closing?

  11. JanTvrdik commented on Dec 19, 2014

    @JanTvrdik
    ContributorAuthor

    Because it's won't fix for know because you have not yet opened a branch that can accept this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions