poco
poco copied to clipboard
Percent-encoded slashes in URI get lost when converted to Poco::URI object
I'm using Poco for a program to provide users the ability to make connections to arbitrary URIs over HTTP. I've recently had a user report to me that when using a URI that explicitly use percent-encoded slashes (to escape path handling), the encoded slash gets converted to just a normal slash and is not converted back out when sending the request. This occurs inside the constructor for Poco::URI
. For example, when creating a Poco::URI
from https://gitlab.com/api/v4/projects/278964/repository/files/public%2Fdeploy.html?ref=master, the path portion of the object becomes api/v4/projects/278964/repository/files/public/deploy.html?ref=master
, and that gets sent to the web server and is rejected. I've tried double-encoding the URL to escape all percents with %25
, but those get expanded out again when sent to the server, resulting in %252F
.
Here's the general code I'm using:
http_param_t* param;
Poco::URI uri;
HTTPClientSession * session;
std::string status;
// ...
try {
uri = Poco::URI(param->url);
} catch (Poco::SyntaxException &e) {
status = "URL malformed";
}
// ...
if (uri.getScheme() == "http") {
session = new HTTPClientSession(uri.getHost(), uri.getPort());
} else if (uri.getScheme() == "https") {
const Context::Ptr context = new Context(Context::CLIENT_USE, "", Context::VERIFY_NONE, 9, true, "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH");
session = new HTTPSClientSession(uri.getHost(), uri.getPort(), context);
} else status = "Invalid protocol '" + uri.getScheme() + "'";
// ...
I've tested this with netcat to host a quick HTTP session. The expected request from the client should look like this (ignoring details of headers):
GET /a%2Fb HTTP/1.1
accept-charset: UTF-8
user-agent: computercraft/1.95.1
host: localhost:8080
connection: close
However, when sent from Poco, the %2F
is replaced with a slash:
GET /a/b HTTP/1.1
User-Agent: computercraft/1.95.3 CraftOS-PC/v2.5.5
Accept-Charset: UTF-8
Connection: Close
Host: 127.0.0.1:8080
When %
is replaced with %25
, this request is sent:
GET /a%252Fb HTTP/1.1
User-Agent: computercraft/1.95.3 CraftOS-PC/v2.5.5
Accept-Charset: UTF-8
Connection: Close
Host: 127.0.0.1:8080
Is there any way to fix this?
This issue is stale because it has been open for 365 days with no activity.
Hi, is there any feedback from the developers?
Here's feedback: you guys have an itch. Scratch it. With all due respect to your problems, we fix things if we deem them important enough.
I'm not saying we won't ever address this, I'm just saying it was not yet deemed important enough for us to look into it. If you need it fixed quick, you can write the fix yourself, write the test case(s), and send us a pull request - that will make it easier for us to look into it. Otherwise, you'll have to wait until we find some time to look into it. I hope you understand.
I myself have already mitigated this issue (a year ago) by using the original string's path segment, with the help of Poco::URI
to determine where to start. I'm not too fussed over it either, and I'd write a PR if a) I had the time, b) knew the best way to approach it, and c) was still affected by the issue. I personally don't need you all to go out of your way to fix it; there are hundreds of other issues reported, of which there's plenty that are of higher importance.
(Side note: it would really be nice if GitHub's issue tracker had user-assignable severity levels built in, like Bugzilla. That would really help developers get through the bad bugs first, as well as let reporters deliberately mark their bugs with the required attention level.)
@aleks-f I was merely wondering what your opinion on this was. I would be more than happy to contribute, however C++ is unfortunately not my area expertise :/
But as you both mentioned, it's not super important and I completely understand your position on this. Thanks for the feedback Aleksandar.
This issue is stale because it has been open for 365 days with no activity.
This issue was closed because it has been inactive for 60 days since being marked as stale.