View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003413 | libmicrohttpd | compliance | public | 2014-05-30 16:10 | 2021-09-02 15:54 |
| Reporter | benjarobin | Assigned To | Christian Grothoff | Due Date | |
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | all | OS | all | OS Version | all |
| Product Version | 0.9.36 | ||||
| Target Version | 0.9.37 | Fixed in Version | 0.9.37 | ||
| Summary | 0003413: Wrong handling of encoded path | ||||
| Description | The bug 0003371 fixed the issue reported but create a major regression... From a browser I tried to access to this URL: "http://127.0.0.1:8080/test%20space/" The url reported by the callback is equal to: "/test%20space/" instead of: "/test space/" | ||||
| Steps To Reproduce | To "debug" it, I just add the following printf inside the minimal_example.c: printf("URL: %s\nmethod: %s\nversion: %s\n\n", url, method, version); The url displayed should be decoded. * "http://127.0.0.1:8080/test%20space/" should give "URL: /test space/" * "http://127.0.0.1:8080/test+space/" should give "URL: /test+space/" | ||||
| Tags | No tags attached. | ||||
| If this bug report is valid, I don't think that it possible to fix 0003371 without breaking the API... The cleaner way to fix the problem it to add a parameter to the UnescapeCallback function. This added parameter will be an enum with the reason of the escaping (URI, parameters, ...). But doing this will break every application that use custom UnescapeCallback. | |
| I can confirm this, we just found this in one of our applications. Before the change we expected "/a%2Bb/" as "/a+b/", now we get this still escaped. While this may be better suiting the spec (especially regarding decoding of "%2F"), it creates a problem with existing apps. It would be helpful if we could get at least an API with the existing function for decoding with different functions/parameters for URI und URI components (like encodeURI/encodeURIComponent in Javascript, the former does not escape reserved characters according to RFC 2396). | |
| Ok, tried to fix this as nicely as I could think in SVN 33463. The unescape callback is simply no longer responsible for escaping '+', that is done in a _separate_ pass in the places where this is appropriate; in return, ordinary (non-+) unescaping is applied to the URIs as well. | |
| Fix committed to master branch. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-05-30 16:10 | benjarobin | New Issue | |
| 2014-05-30 16:55 | benjarobin | Note Added: 0008369 | |
| 2014-06-01 21:19 | texec | Note Added: 0008374 | |
| 2014-06-01 21:19 | texec | Note Edited: 0008374 | |
| 2014-06-01 22:10 | Christian Grothoff | Note Added: 0008375 | |
| 2014-06-01 22:10 | Christian Grothoff | Status | new => resolved |
| 2014-06-01 22:10 | Christian Grothoff | Fixed in Version | => 0.9.37 |
| 2014-06-01 22:10 | Christian Grothoff | Resolution | open => fixed |
| 2014-06-01 22:10 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2014-06-01 22:10 | Christian Grothoff | Target Version | => 0.9.37 |
| 2014-06-01 22:16 | Christian Grothoff | Status | resolved => closed |
| 2021-09-02 15:54 | Christian Grothoff | ||
| 2021-09-02 15:54 | Christian Grothoff | Note Added: 0018204 |