Open Bug 1605540 Opened 5 years ago Updated 2 years ago

"Copy as cURL (Windows)" --compressed option is not understood by Windows 10's libcurl

Categories

(DevTools :: Netmonitor, enhancement, P3)

Unspecified
Windows 10
enhancement

Tracking

(firefox-esr68 affected, firefox71 affected, firefox72 affected, firefox73 affected)

Tracking Status
firefox-esr68 --- affected
firefox71 --- affected
firefox72 --- affected
firefox73 --- affected

People

(Reporter: cpeterson, Unassigned)

References

Details

This problem was reported on Twitter by Daniel Stenberg, the author of curl:

"Yesterday I wanted to show off copy-as-curl from Firefox and pasted one into a Windows 10 cmdline. Bzzzt. Total fail. Microsoft never enabled the --compressed option in curl, so basically half of all such attempts won't work! =-("

https://mobile.twitter.com/bagder/status/1207921081371299840

What were you doing?

  1. Load http://www.example.com/
  2. Open DevTools' Network tab
  3. Right-click on the favicon.ico request
  4. Select "Copy > Copy as cURL (Windows)" menu command
  5. Open cmd.exe
  6. Paste the cURL command into cmd.exe and try to run it

What happened?

The curl command includes the --compressed command line option, which is not understood by curl.exe:

curl "http://www.example.com/favicon.ico" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0" -H "Accept: image/webp,*/*" -H "Accept-Language: en-US,en;q=0.5" --compressed -H "DNT: 1" -H 

"Connection: keep-alive"
curl: option --compressed: the installed libcurl version doesn't support this
curl: try 'curl --help' for more information

What should have happened?

"Copy as cURL (Windows)" should be compatible with Windows' curl.exe command.

Anything else we should know?

Oddly, my curl.exe understands --compressed but my installed libcurl does not. I am running Microsoft Windows 10 Pro Version 10.0.19041 Build 19041 (Windows Insider "Slow" ring).

My curl --version:

curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
Release-Date: 2017-11-14, security patched: 2019-11-05
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL

Bug 1052856 (Firefox 34) replaced -H "Accept-Encoding: gzip, deflate" with --compressed. My Windows' libcurl understands -H "Accept-Encoding: gzip, deflate", but the disadvantage is that curl.exe won't automatically decompress the compressed HTTP response. You must specify an output file (--output favicon.ico).

curl checks with libcurl if compression is supported and if not, it outputs this.

For some reason Microsoft decided to not build their bundled curl version to support this very commonly used feature. Virtually everyone else is going to have support for it, including those that download curl from the curl web site or install it from other third party locations. The WSL versions are also likely to have it supported.

(In reply to Daniel Stenberg [:bagder] from comment #1)

curl checks with libcurl if compression is supported and if not, it outputs this.

Could we somehow check the support dynamically from code before generating the curl command?

Not sure what is the expectation here, any suggestions how it should work?

Honza

Flags: needinfo?(daniel)
Priority: -- → P3

It is possible but I imagine it would also be error-prone.

The tool curl has a --version (or -V) option that outputs information about what it supports. One of the output lines start with "Features:" and that line includes a list of named features this particular curl supports. It lists the features named "libz" and/or "brotli" if it supports one or both of those compressions. If none of them are supported, using --compressed will cause that error message to help the user understand that they ask for something that isn't there (in this build).

However, users often have multiple curl installations and it isn't totally unlikely that users on Windows that get a (by now) rather old curl version with their OS that lacks this support, install a modern curl version from the official curl site and that will support this option.

So, Firefox wouldn't know which curl tool to check or which of those curl installations the user would be likely to use when they would invoke the command line copied from Firefox.

(Why on earth couldn't Microsoft just have enabled this?)

Flags: needinfo?(daniel)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.