curl tool option to percent-encode the passed raw URL

[vszakats]

In certain situations it'd would be useful if curl (the tool) could translate a raw URL (f.e. containing spaces or other special characters) passed to its command-line to the percent-encoded (AKA 'URL encoded') version that would then be used to make the actual request.

This could be handy on Windows mainly, where the % sign has special uses, so including it in a command may be problematic (needs different escaping on the command-line, inside a batch file, in shell script), or impossible.

So f.e. this line:

curl -O https://example.com/hello%20world.txt

could become:

curl -O "https://example.com/hello world.txt" -rawurl

Required low-level logic is already implemented in the codebase as curl_easy_escape().

[bagder]

One problem would be that you probably don't want it to become fully "URL encoded" (as said libcurl function would make it) as then for example the slashes would also be encoded... It sounds to me like you're looking to getting some specific letters to get encoded, like space for example.

[vszakats]

Yes, exactly, thanks for pointing that out. Spaces, percent-sign look like good candidates to start with.

(I've updated the original message.)

[vszakats]

@patrikhson Looks like something is spamming this space on your behalf.

[bagder]

Yeah and I have no way to block a specific user or email address other than to report them for abuse but I did it now in an attempt to stop this flood.

[kdudka]

On Tuesday, July 12, 2016 08:28:02 Daniel Stenberg wrote:

Yeah and I have no way to block a specific user or email address other than
to report them for abuse but I did it now in an attempt to stop this
flood.

So did I (together with request to delete the comments). Then I spotted that
@patrikhson posted a "normal" comment in 2013. Looks like somebody hacked his
account recently.

[bagder]

Yes I know Patrik Fältström so I know this isn't him. But AFAIK there's nothing preventing you from sending emails to github and just forging the From address.

[vszakats]

I believe it's not enough to spoof the sender address to be able to post to spaces like this. One needs to also obtain a valid reply address, which is identifying the discussion (and possibly the participant as well), and which looks like this in case of GitHub:

reply+<very-long-unique-hex-id> (AT) reply.github.com

Assuming such reply ID cannot be easily spoofed, it's likely they are being harvested from email archives and used as target addresses.

[vszakats]

One stop-gap solution is to lock old Issues and other places where he appears as participant.

[patrikhson]

I have noted this but will be in an airplane for two hours. Will be online approx 1800 UTC.

Patrik

On 12 juli 2016, at 17:39, Viktor Szakats notifications@github.com wrote:

One stop-gap solution is to lock old Issues and other places where he appears as participant.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[patrikhson]

FWIW, I am cleaning up now. I have no real idea what has happened...

[jay]

No that shouldn't be necessary. I wrote GitHub about this and they are going to look into that account to improve their spam protection. Clearly no person would post that many messages in such a short period of time, only an automated process. The content was also suspect.

Collaborators are limited in how they can handle abuse like this to reporting it, Owners however can throw down the hammer I believe by ignoring the user because when you ignore a user it should ban them from posting comments in any repos they own. That may be different for organizations (which we are) so @bagder should this happen again you could also try https://help.github.com/articles/blocking-a-user-from-your-organization/

[bagder]

I noticed already 10 hours ago that github admins had removed the spam comments (I think several of us reported the incident). At least all the ones I checked.

[ghost]

@bagder its nice that you added this to the TODO list, but that doesnt really, or shouldnt really close this issue

also that was about 2 years ago

[bagder]

@svnpenn: we don't keep issues open if nobody intends to work on them: https://curl.haxx.se/docs/bugs.html#Closing_off_stalled_bugs