I wasn't planning to do much with cURL, just remove the
things which annoyed me, but Marty Kuhrt, the fellow who was
tending the VMS stuff seems to be short on time and/or
interest, so here we are.
Now I'm trying to get these changes adopted by the cURL
folks, who would be interested in any comments from VMS users,
of which there seem to be few who follow the curl-library
e-mail list. Anyone who cares should be able to find my stuff
(loose files, and a ".dru" ("diff -ru" output) file) at:
http://antinode.info/ftp/curl/curl-7_19_7/
Comments can be directly to the curl-library list, or I can
respond to or pass along any comments made here.
I never had problems with the builds on ODS5. I built it on VAX, Alpha
and IA64 from the same disk/dir.
The DECC$SYSTEM_INCLUDE logical was done because a while back the cURL
maintainers had made some incorrect assumptions about which way includes
should be done. They may have fixed it. Since it built fine, I didn't
change it.
To each his own. I find defining things in DCL easier to work with and
change that having to do all that changing the C code nonsense. You
change it, you maintain it.
Enjoy.
I don't use cURL, but if I may add a few general comments
anyway.
Unless those maintainers have tested your changes on a VMS
system and have specific reasons to not like the changes,
then they should add it.
It is a lot easier if all changes to get an open source
project to build and run in a certain environment get
included in the base version.
And if someone with a X system considers it a good
change and the maintainer does not have a X system,
then it should just be included.
That is the only way to do multi OS open source
efficiently.
Arne
I have CURL building under GNV now. Recent binaries for Alpha 8.3 have
been available on the Encompasserve.org FTP site. This includes a
libcurl shared image.
I sent you some notes on the changes I have made, but did not get any
responses. Several of my changes have been checked into the CURL
library. I ran out of time to negotiate the remaining changes in.
-John
wb8...@qsl.network
Personal Opinion Only
I can do
$ curl "--version"
curl 7.18.2 (ALPHA-HP-VMS) libcurl/7.18.2 OpenSSL/0.9.7e
Protocols: tftp ftp telnet dict http file https ftps
Features: NTLM SSL
$
and I can do:
> $ curl "-I" "http://www.weatheroffice.gc.ca/radar/index_e.html?id=XFT"
> HTTP/1.1 200 OK
> Date: Wed, 30 Dec 2009 06:49:58 GMT
> Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch15 mod_perl/2.0.2 Perl/v5.8.8
> X-Powered-By: PHP/5.2.0-8+etch15
> Set-Cookie: product=%22precip_snow%22
> Set-Cookie: duration=%22short%22
> Set-Cookie: overlays=%5B%22overlay_default_cities%22%2C%22overlay_roads%22%2C%22
> overlay_radar_circle%22%5D
> Connection: close
> Content-Type: text/html; charset=ISO-8859-1
>
> $
BUT !!!!
$ curl "http://www.weatheroffice.gc.ca/radar/index_e.html?id=XFT"
hangs in LEF mode forever. No activity. No error message. This worked
for a long time and stopped working yesterday (this is a job that runs
in detached mode 7/24, and is reproducible in interactive mode.
(This is on Alpha 8.3 with TCPIP Services 5.6)
Any ideas what would cause this ?
> (This is on Alpha 8.3 with TCPIP Services 5.6)
As usual, actual output from "tcpip show version" would be
better than a vague description.
> Any ideas what would cause this ?
No. Around here (although the quotation isn't really
needed):
alp $ curl "http://www.weatheroffice.gc.ca/radar/index_e.html?id=XFT"
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://
www.w3.org/TR
/xhtml1/DTD/xhtml1-strict.dtd">
[...]
alp $ curl --version
curl 7.19.7 (ALPHA-HP-VMS) libcurl/7.19.7 OpenSSL/0.9.8j
Protocols: tftp ftp telnet dict http file https ftps
Features: Largefile NTLM SSL
alp $ tcpip show version
HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 4
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.3
I know nothing, but I suspect that cURL offers options to
enable some verbosity and/or debug output.
alp $ curl --help
[...]
--trace <file> Write a debug trace to the given file
--trace-ascii <file> Like --trace but without the hex output
--trace-time Add time stamps to trace/verbose output
[...]
-v/--verbose Make the operation more talkative
[...]
Just a thought.
> --trace <file> Write a debug trace to the given file
> --trace-ascii <file> Like --trace but without the hex output
$ curl --trace-ascii temp.txt -
"http://www.weatheroffice.gc.ca/radar/index_e.html?id=XFT"
Interrupt
$ exit
$ type temp.txt
== Info: About to connect() to www.weatheroffice.gc.ca port 80 (#0)
== Info: Trying 199.212.17.28... == Info: connected
== Info: Connected to www.weatheroffice.gc.ca (199.212.17.28) port 80 (#0)
=> Send header, 157 bytes (0x9d)
0000: GET /radar/index_e.html?id=XFT HTTP/1.1
0029: User-Agent: curl/7.18.2 (ALPHA-HP-VMS) libcurl/7.18.2 OpenSSL/0.
0069: 9.7e
006f: Host: www.weatheroffice.gc.ca
008e: Accept: */*
009b:
$
When doing the --verbose, it yields the same information. It logs the
sending of the HTTP header, and then hangs before displaying any of the
server's reply.
OK, now even the -I hangs. But I can still telnet/port=80 to the web
server and send and receive stuff.
Probably some really odd thing deep down in the bowels of the TCP stack
that cause curl to hang when waiting for input.
I'll do an ana/image on the .exe for curl after it is done just in case
the file might have gotten corrupt.
I had to reboot my router. My guess that its NAT table was full or
something. Works fine now. Even FETCH_HTTP had that behaviour for
certain external web sites.
Apology for having hijacked this thread !