bruce | 3 Feb 16:58 2016

simple question -- i must be missing something


Trying to figure out how to capture content from the following url. As
far as I can tell using FF/Livehtpheaders/etc... it's a get that
should be implemented. Basically, trying to figure out how to
programatically get the career/term as listed in the page.

using the following urls:

In a browser, the displayed content lists the career (undergrad/grad),
and term data fields.

Using the
   --the term(s) can be gotten.

However, I'm at a loss as to how to get the career.

When you look (using the source) of the browser, you can see the
career/term from the  "" url

However, I can't seem to generate a curl to get the same results

Since the site, allows the user to get to the class, via the main
page, guest page, class page, a test using curl to simulate that
process didn't work either..
(Continue reading)

Irvin Jacob | 1 Feb 16:18 2016

Curl --data-urlencode posts broken non-English characters

I am using curl to reply to a topic in a vBulletin forum from a text file.

My command looks like this:

curl -b "cookies.txt" -d "title=" --data-urlencode "message_backup <at> message.txt" --data-urlencode "message <at> message.txt" -d "wysiwyg=0" -d "iconid=0" -d "s=" ... "" -L

Note that I just wrote "..." above because the command is too long.

message.txt has Japanese text "大日本帝國" inside and it is encoded in UTF-8. Curl successfully posted the message but the Japanese characters turned into "大日本å¸åœ‹" in my message posted on the forum. Other normal (ASCII) characters look fine though. I also tried other foreign characters like Greek letters and accented letters. "Thére Àre sôme spëcial charâcters ïn thìs têxt" became "Thére Àre sôme spëcial charâcters ïn thìs têxt"

I tried specifying the header Content-Type: application/x-www-form-urlencoded; charset=UTF-8 via -H option. I tried adding --compressed and --tr-encoding options. I also tried different versions of curl. All of these did not change anything.

Could somebody please help me?


This email has been sent from a virus-free computer protected by Avast.
List admin:
Sasikala Raju | 1 Feb 15:23 2016

FTP List files and directories

Hi Team,


I would like to know if there is any better way to list files and directories and differentiate between files and directories.


CURLOPT_DIRLISTONLY will list the name of files and dirs. Is there metadata to know if it is file or directory ?


Parsing the FTP response as such might not be good idea, since serve response differs for different OS.






***************************Legal Disclaimer*************************** "This communication may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message by mistake, please advise the sender by reply email and delete the message. Thank you." **********************************************************************
List admin:
Makoto Fujiwara | 1 Feb 14:13 2016

typo on example makes 'make check' to fail.

Hi, thanks for supporting curl, it is one of the most
frequent used package for our community, thanks.

By the way, I'm compiling 7.47.0 and also checked with
make check.

It turned out minor typo is in in docs/examples/getredirect.c
and I needed attached patch for make test to pass,

My environment: NetBSD/amd64 7.99.25

Thanks a lot,
Makoto Fujiwara, 
mef <at> NetBSD
Chiba, Japan, Narita Airport and Disneyland prefecture.
Key fingerprint = 0BFA FAEB EAD1 90BA 7498  8F85 6809 9E0B B7EF A12E

Simple type for examle code, but this need make test to pass
(when PKGSRC_TEST_RUN= yes).

--- docs/examples/getredirect.c~        2016-01-15 00:37:49.000000000 +0900
+++ docs/examples/getredirect.c 2016-02-01 21:52:01.000000000 +0900
 <at>  <at>  -48,7 +48,7  <at>  <at>  int main(void)
     else {
       res = curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response_code);
       if((res == CURLE_OK) &&
-         ((code / 100) != 3)) {
+         ((response_code / 100) != 3)) {
         /* a redirect implies a 3xx response code */
         fprintf(stderr, "Not a redirect.\n");

List admin:
Octavio Schroeder | 29 Jan 16:56 2016

Windows cURL command line tool output problem

I was doing some testing today with the latest cURL build 7.47.0.


I believe the issue is related to the recent fix for the CVE-2016-0754 issue (


C:\temp>curl --version

curl 7.47.0 (x86_64-pc-win32) libcurl/7.47.0 OpenSSL/1.0.2f zlib/1.2.8 WinIDN libssh2/1.6.0 nghttp2/1.7.0

Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp

Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2


Tried downloading a file as follows:


curl -o c:\temp\google.html


The output does not get saved in a file called google.html in the C:\temp folder but ‘c__temp_google.html’ in the current working folder.


curl -o \temp\google.html


The output does not get saved in a file called google.html in the \temp folder on the current drive but ‘_temp_google.html’ in the current working folder.


This indicates that colons and backslashes are converted to underscrores even for the -o command


The advisory indicates that this issue only applies to using the uppercase O and J options (and their respective long versions) but it seems to also affect the lower-case -o option as well as the --output.


The 7.46 build is not affected by this.


Octavio Schroeder

Lead Product Engineer

Cogeco Peer 1

Unstoppable Enterprises Live Here


List admin:
Daniel Stenberg | 27 Jan 08:46 2016

[SECURITY ADVISORY] remote file name path traversal in curl tool for Windows

remote file name path traversal in curl tool for Windows

Project cURL Security Advisory, January 27th 2016 -


curl does not sanitize colons in a remote file name that is used as the local
file name. This may lead to a vulnerability on systems where the colon is a
special path character. Currently Windows is the only OS where this
vulnerability applies.

curl offers command line options --remote-name (also usable as -O) and
--remote-header-name (also usable as -J). When both of those options are used
together (-OJ) and the server provides a remote file name for the content,
curl will write its output to that server-provided file name, as long as that
file does not already exist. If it does exist curl will fail to write.

If both options are used together (-OJ) but the server does not provide a
remote file name, or if -O is used without -J, curl will write output to a
file name based solely on the remote file name in the URL string provided by
the user, regardless of whether or not that file already exists.

In either case curl does not sanitize colons in the file name. As a result in
Windows it is possible and unintended behavior for curl to write to a file in
the working directory of a drive that is not the current drive (ie outside the
current working directory), and also possible to write to a file's alternate
data stream.

For example if curl -OJ and the server sends filename=f:foo curl will
incorrectly write foo to the working directory for drive F even if drive F
isn't the current drive. For a more detailed explanation see the 'MORE
BACKGROUND AND EXAMPLE' section at the end of this notice.

Though no known exploit is available for this issue, writing one would be
undemanding and could be serious depending on the name of the file and where
it ends up being written.


This flaw only affects the curl command line tool as this is a feature not
present or provided by libcurl.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2016-0754 to this issue.


In the case of using a remote file name provided by the user (-O without -J),
the feature has existed since inception. <- check this I'm not sure.

- Affected versions (-O): curl <= 7.46.0
- Not affected versions (-O): curl >= 7.47.0

In the case of using a remote file name provided by the server (-OJ), the
feature was added in 7.20.0 and didn't exist before then.

- Affected versions (-OJ): curl 7.20.0 to and including 7.46.0
- Not affected versions (-OJ): curl < 7.20.0 and curl >= 7.47.0


Starting in curl 7.47.0 the curl tool in Windows will replace all colons in a
remote file name with underscores. For example if f:foo::$DATA is the remote
file name it will be sanitized as f_foo__$DATA .

A patch is available at:

Exercise judicious use of the -J option. The -J option when combined with -O
lets the server choose the file name. Do you trust the server you are using
the -J option on? Is your connection to the server vulnerable to a
man-in-the-middle attack? Have you enabled location redirects and the server
may send you somewhere untrustworthy? In any of these cases, even with this
vulnerability fixed know that if you use the -J option it will still be
possible for a rogue server to send you the name of a DLL or other file that
could possibly be loaded automatically by Windows or some third party


We suggest you take one of the following actions immediately, in order of

  A - Upgrade curl and libcurl to version 7.47.0.

  B - Apply the patch to your version and rebuild.

  C - If you cannot do (A) or (B) it is suggested you do not use -J on Windows.
      If you choose to continue to use -O without -J it is your responsibility
      to check that the URL you pass does not have a remote file name that could
      be exploited.

Regardless of which action you take, exercise judicious use of the -J option as
described in THE SOLUTION.


It was first reported to the curl project on November 30 2015. We contacted
distros <at> openwall on January 21 2016.

curl 7.47.0 was released on January 27 2016, coordinated with the publication
of this advisory.


Reported and patched by Ray Satiro (Jay).

Thanks a lot!


In Windows if a colon is used to specify a drive letter for a path and there
is a slash or backslash (hereafter path separator) that proceeds the colon it
means start from the root of the drive, but if that slash is omitted it means
start from the current working directory of the drive.

  - C:\foo => Windows looks for foo in the root directory of drive C.
  - C:foo => Windows looks for foo in the working directory of drive C.


A process in Windows on its creation may inherit a list of drives and their
working directories from its parent, and one of those is the current working

For example a command prompt is open and has these working directories:

  - Drive C, Path \bar\baz\
  - Drive D, Path \
  - Drive E, Path \qux\    <-- Current
  - Drive F, Path \

Assume other drives were not accessed which means they default to their root.

A user running curl from that command prompt would expect that their file will
be output to the current working directory, E:\qux\ in this example. However
that may not happen if there is a colon in the filename.

curl has a function which will strip the path to get the file name by removing
the last path separator and everything that precedes it. In the case of a colon
without a path separator that comes after it, it is not removed from the file

Following this example:

In the case of -O without -J recall that the filename is parsed from the user-
supplied URL, and is written regardless of whether the file already exists.

`curl -O http://somewhere/f:foo` => curl writes output to f:\foo

`curl -O http://somewhere/c:foo` => curl writes output to c:\bar\baz\foo

In the case of -O with -J recall that the file name is parsed from the
server's "Content-Disposition:" header if one is given (eg
`Content-Disposition: attachment; filename=abc`) and in that case the file is
written only if it does not already exist.

`curl -OJ http://somewhere/somefile` => Server sends filename=f:foo
                                         curl writes output to f:\foo

`curl -OJ http://somewhere/somefile` => Server sends filename=c:foo
                                         curl writes output to c:\bar\baz\foo



List admin:
Uday C | 25 Jan 13:55 2016

Re: curl-users Digest, Vol 125, Issue 5

Hi Daniel,

Thanks for the reply.

1)the error message i am facing is as mentioned below

* TLSv1.0, TLS handshake, Client hello (1):
* TLSv1.0, TLS alert, Server hello (2):
* error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
* Closing connection 0
curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

2)SSL version

    i am not completely sure about this as of now i am using the binaries(dlls,static libraries) that was provided for mingw for 32bit windows OS 7.40.0 version
3) i want the libcurl 7.46.0 and dependent libraries(dll's and static libraries) corresponding to the version which was built on mingw for 32bit windows OS.
    From the curl download page i was able to get the same for the 7.40.0 version but as it seems there are some bugs related to SSL and TLS which were fixed latter versions hence i need the same for 7.46.0


On Mon, Jan 25, 2016 at 4:30 PM, <curl-users-request <at>> wrote:
Send curl-users mailing list submissions to
        curl-users <at>

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
        curl-users-request <at>

You can reach the person managing the list at
        curl-users-owner <at>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of curl-users digest..."

Today's Topics:

   1. Re: libcurl 7.46.0 SSL version build (Daniel Stenberg)


Message: 1
Date: Sun, 24 Jan 2016 23:48:52 +0100 (CET)
From: Daniel Stenberg <daniel <at>>
To: the curl tool <curl-users <at>>
Subject: Re: libcurl 7.46.0 SSL version build
Message-ID: <alpine.DEB.2.20.1601242343140.2590 <at>>
Content-Type: text/plain; format=flowed; charset=US-ASCII

On Sun, 24 Jan 2016, Uday C wrote:

For libcurl issues and discussions, we recommend using the curl-library
mailing list instead. This list is intended for the command line tool curl.

Also, it is considered a good idea to paste error messages as plain text
instead of images of text in emails to allow more users to easily read your
email and it makes the emails more searchable and findable in a future. I had
to go through hoops to figure out what you were talking about.

> the webserivce which i am trying to connect to support only support TSL1.1.
> and TSL1.2 when i installed and checked 7.46.0 i am able to connect to web
> service all the time without any issues

Which SSL library and version are you using?

> 1) do we have any bug in libcurl7.40.0 which is fixed in latter version

Yes, more than 450 documented bug fixes in fact.

> 2) is there any way that i can fix this ?

I bet, but we need to some further debugging to figure out why it happens.

> 3) Can you please provide the libcurl 7.46.0 dlls for below version

I don't understand. I can see several libcurl packages with 7.46.0 in that




Subject: Digest Footer

curl-users mailing list
curl-users <at>


End of curl-users Digest, Vol 125, Issue 5

List admin:
Uday C | 24 Jan 18:09 2016

libcurl 7.46.0 SSL version build

Hi All,

i am using the libcurl 7.40.0 dlls for my application.
When i am using this i see few times i am able to connect to web service and few time i am getting below error 

the webserivce which i am trying to connect to support only support TSL1.1. and TSL1.2
when i installed and checked 7.46.0 i am able to connect to web service all the time without any issues

Can you please help in the following

1) do we have any bug in libcurl7.40.0 which is fixed in latter version
2) is there any way that i can fix this ?
3) Can you please provide the libcurl 7.46.0 dlls for below version

Thanks for your help.

List admin:
Dan Fandrich | 12 Jan 23:29 2016

Proxy Auto-Config with curl

I just ran across this page describing one of the features of Intel's Clear
Linux, namely system-wide PAC file support using libcurl:  What they've done is to run a daemon
sitting on D-Bus that interprets PAC files and have a modified libcurl pass all
its URLs to the daemon for rewriting before acting on them.  If the daemon
isn't available or no PAC file is needed, libcurl just acts normally.

It sounds like a nifty way to make many system programs instantly and
automatically support proxies via PAC files. This question comes up on this
list often, so this might be a solution for some.

>>> Dan
List admin:
Christian Weisgerber | 1 Jan 22:09 2016

zsh completions fix

It looks to me like the zsh completions aren't generated correctly in
7.46.0 (and still unfixed in the git repo).

scripts/ parses the output of "curl --help", but if curl(1) isn't
already installed, this won't work.  A full path to curl can be passed
as the first argument to, so let's use this:

---	2016-01-01 21:50:34.856844000 +0100
+++	2016-01-01 21:51:03.190722000 +0100
 <at>  <at>  -28,7 +28,7  <at>  <at> 

 	 <at> if ! test -x "$(PERL)"; then echo "No perl: can't install"; exit 0; fi
-	$(PERL) $(srcdir)/ > $ <at> 
+	$(PERL) $(srcdir)/ $(top_builddir)/src/curl > $ <at> 



Christian "naddy" Weisgerber                          naddy <at>
List admin:
belen esteban | 27 Dec 00:24 2015

IIS 8 sends negotiate, accepts ntlm and neither ntlm nor anyauth works in curl

Cant get curl working, it appears to me that it's due to someting related with this server response: www-authenticate:negotiate (single line; there is no next line with the authenticate:NTLM alternative. -iis8, 2012r2 server-). 
The working sequence I got from fiddler and IE11 is like this:
Client: get http ....
Server: 401, www-authenticate:Negotiate
Client: Authorization: Negotiate NTLMSSP.......... type 1 message
Server: 401, www-authenticate:Negotiate NTLMSSP .... type 2 message
Client: type 3 message
Server: 200
But I can't get it working in curl; i've tried --anyauth, --ntlm , etc with no result; the trace stops always in the first 401. (last sources from github with almost all options compiled in)
Any ideas? 
thanks in advance
List admin: