Skip to content

MultipartRequest of the Http package percent-encodes form field names #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
DartBot opened this issue Jun 5, 2015 · 4 comments
Closed
Assignees
Labels
type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@DartBot
Copy link

DartBot commented Jun 5, 2015

Originally opened as dart-lang/sdk#17899

This issue was originally filed by [email protected]


What steps will reproduce the problem?

  1. Create an instance of MultipartRequest as your HTTP request.
  2. Add a form field to your request object created in step 1 with a name that contains non-alphanumeric (but still ASCII contained) characters, such as the string: "login[username]".
  3. POST the form, for example with this code: new http.Client().send(yourRequestObject);

What is the expected output? What do you see instead?
The form field's name should stay untouched, but the braces get percent encoded and the request gets rejected by the server (tested with PHP/5.4.4-14+deb7u8 plus nginx/1.2.1)

What version of the product are you using? On what operating system?
OS X 10.9.2
Dart SDK 1.2.0

Please provide any additional information below.

The source of the problem is this code snippet from packages/http/src/multipart_request.dart
var header = 'content-disposition: form-data; name="${Uri.encodeFull(name)}"';

The previous snippet's comment (pasted below) states that this is intended and the goal was to reproduce the behaviour of browsers.
Still, posting a form with the mentioned field name included, both Chrome and Firefox will leave it as is, and the POST will be accepted by the same back-end mentioned above.

// http://tools.ietf.org/html/rfc2388 mandates some complex encodings for
// field names and file names, but in practice user agents seem to just
// URL-encode them so we do the same.

I understand that implementing the 'complex encodings' can be kind of a grunt work, without too much leverage. But even simply leaving out the encoding would be better for my use-case.

I also wonder if there is already a well written utility class exactly for the mentioned 'complex encoding' somewhere in the chromium source. If yes, that probably could help a lot, simplifying the task to a C => Dart translation, just guessing here.

Anyways, from my side the only goal would be to make the same forms work that are working well on the major browsers already, maybe those aren't even RFC compliant either.

Peter

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/8631949?v=3" align="left" width="48" height="48"hspace="10"> Comment by floitschG


Added Area-IO, Triaged labels.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/1343914?v=3" align="left" width="48" height="48"hspace="10"> Comment by sgjesse


Removed Area-IO label.
Added Pkg-Http label.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3


Set owner to @nex3.
Added Started label.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3


Fixed by dart-lang/sdk@a750dea.


Added Fixed label.

@DartBot DartBot added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) Fixed labels Jun 5, 2015
@DartBot DartBot closed this as completed Jun 5, 2015
natebosch added a commit that referenced this issue Apr 13, 2021
Named arguments are non-nullable with a default instead of a null
default. This means that code which was passing null through instead of
omitting the argument will be broken, even in unsound mode. I don't
expect any code was doing this, and this API is not one that should need
to be wrapped with argument forwarding.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

2 participants