[Bug-wget] New Developer

[Charles Jackson via Bug-wget]

Hellow, I would like to join the development team for Wget. What can I do to 
get started.

[Bug-wget] [bug #48193] Build fails unless -liconv set explicitly in LDFLAGS

[Charles]

Follow-up Comment #16, bug #48193 (project wget):

I commented out that line.

Autoreconf emitted this warning: configure.ac:499: warning: macro
'AM_PATH_GPGME' not found in library

Then running ./configure ended with: ./configure: line 44129: syntax error
near unexpected token `fi'
./configure: line 44129: `fi'

Apparently the entire else-block needed removal.  I did that, and then started
over.  Autoreconf still emits the warning, but then ./configure succeeded and
so did the subsequent `make`.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-wget] [bug #48193] Build fails unless -liconv set explicitly in LDFLAGS

[Charles]

Follow-up Comment #14, bug #48193 (project wget):

Ok, I uploaded those two things.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-wget] [bug #48193] Build fails unless -liconv set explicitly in LDFLAGS

[Charles]

Additional Item Attachment, bug #48193 (project wget):

File name: config.h   Size:88 KB
File name: config.log Size:1765 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-wget] [bug #48193] Build fails unless -liconv set explicitly in LDFLAGS

[Charles]

Follow-up Comment #12, bug #48193 (project wget):

More info: it seems to be something about this particular set of config flags:
--with-ssl=openssl --with-libssl-prefix=/usr/local/ssl --disable-pcre
--disable-iri

If I simply get rid of the --disable-iri flag, 1.19.1 will build find on macOS
10.12.3.  If I readd that flag, I get the exact error message that started
this thread.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-wget] [bug #48193] Build fails unless -liconv set explicitly in LDFLAGS

[Charles]

Follow-up Comment #11, bug #48193 (project wget):

This is not fixed as of 1.19.1.  I just tried building it on macOS 10.12.3 and
got the exact error that initiated this thread.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-wget] [bug #50223] wget 1.19 will not build on MacOS 10.12.3

[Charles]

URL:
  

 Summary: wget 1.19 will not build on MacOS 10.12.3
 Project: GNU Wget
Submitted by: chdiza
Submitted on: Fri 03 Feb 2017 04:14:45 PM GMT
Category: Build/Install
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: chdiza
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.19
Operating System: Mac OS
 Reproducibility: Every Time
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

I never had any problems with wget 1.18, but trying to build 1.19 with the
same ./configure flags as before will fail to build.  My flags are: 
  --with-ssl=openssl
  --with-libssl-prefix=/usr/local/ssl
  --diasble-pcre
  --disable-iri

The `make` step fails with this:

--8<
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
  CC   connect.o
  CC   convert.o
  CC   cookies.o
  CC   ftp.o
ftp.c:1466:19: error: no member named 'rpl_unlink' in 'struct options'
  if (opt.unlink && file_exists_p (con->target))
  ~~~ ^
../lib/unistd.h:1851:19: note: expanded from macro 'unlink'
#   define unlink rpl_unlink
  ^
1 error generated.
make[3]: *** [ftp.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
8<-






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [Bug-wget] Wget 1.16.1 detection of non-system openssl broken on MacOSX.

[Charles Diza]

On Thu, Dec 25, 2014 at 8:29 AM, Tim Rühsen  wrote:

> Am Donnerstag, 18. Dezember 2014, 16:06:01 schrieb Jochen Roderburg:
> > Hi Tim,
> >
> > Am 16.12.2014 um 14:00 schrieb Tim Ruehsen:
> > > That is not so easy, since when having
> > > --with-libssl-prefix=/usr/local/ssl,
> > > you can't just
> > > OPENSSL_CFLAGS=$with_libssl_prefix/include
> > > OPENSSL_LIBS=$with_libssl_prefix/lib
> > > You also have to manually specify the libraries you want to link
> with...
> > > this can be different on different systems.
> >
> > You are right, and this does also not ensure that the wanted libraries
> > are actually used at run-time, on Linux e.g. the OPENSSL_LIBS must also
> > somehow be in the dynamic library load path.
> >
> > > So I decided to set PKG_CONFIG_PATH before the check and unset it
> > > afterwards. It works for me... but I failed to test it without
> > > pkg-config. Without pkg- config I couldn't get autoreconf working :-(
> >
> > Unfortunately this approach has the same problems as it also does not do
> > more than set the inlcude and lib paths.
> >
> >
> > I made the following experiments on my Linux:
> >
> > Installed a current OPENSSL from source in /usr/local/openssl (with
> > openssl configure:  ./config --prefix=/usr/local/openssl shared)
> >
> > Configured and built wget 1.16.1 with your PKG_CONFIG_PATH patch (with
> > wget configure: configure --with-ssl=openssl
> > --with-libssl-prefix=/usr/local/openssl).
> >
> > With an active pkg-config program I see now the following in the config
> > summary:
> > CFlags:  -I/usr/include/uuid   -I/usr/local/openssl/include
> > -DHAVE_LIBSSL   -DNDEBUG
> > Libs:-lpcre   -luuid   -L/usr/local/openssl/lib -lssl -lcrypto -lz
> >-lidn
> >
> > So the compile and link phase will use the wanted files, but a ldd on
> > the resulting wget binary still shows:
> >
> >  libssl.so.1.0.0 => /lib/libssl.so.1.0.0
> >  libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0
> >
> > With a deactivated pkg-config program the old library detection code
> > seems to be used and I get:
> >
> > CFlags:   -DNDEBUG -I/usr/local/openssl/include
> > Libs: /usr/local/openssl/lib/libssl.so
> > /usr/local/openssl/lib/libcrypto.so
> >Wl,-rpath -Wl,/usr/local/openssl/lib/ -ldl -lz  -lidn -luuid
> > -lpcre
> >
> > and ldd shows now:
> >
> >  libssl.so.1.0.0 => /usr/local/openssl/lib/libssl.so.1.0.0
> >  libcrypto.so.1.0.0 => /usr/local/openssl/lib/libcrypto.so.1.0.0
> >
> > The wanted openssl libraries are inserted here with full path names and
> > really used.
> >
> >
> > Therefore I see now only one possibility to keep these two prefix
> > options without more problems and new questions, namely skip the
> > pkg-config based completely for the SSL libraries if these options are
> > used.
>
> I attached a patch to skip pkg-config detection when --with...-prefix is
> given.
> It works for me, but please also review and test.


I'm unable to apply the patch.  It won't `patch -p1` to a freshly untarred
wget.1.16.1.

However, I also tried cloning the git repo and building from there.  It
worked: --with-libssl-prefix=/usr/local/ssl was recognized.

Cheers,
Charles

Re: [Bug-wget] Wget 1.16.1 detection of non-system openssl broken on MacOSX.

[Charles Diza]

On Fri, Dec 12, 2014 at 11:15 AM, Tim Ruehsen  wrote:

> On Thursday 11 December 2014 11:51:27 Charles Diza wrote:
> > On Thu, Dec 11, 2014 at 4:39 AM, Tim Ruehsen  wrote:
> > > On Wednesday 10 December 2014 12:02:32 Charles Diza wrote:
> > > > Wget 1.16.1 has broken detection of non-built-in openssl on MacOSX.
> > > >
> > > > Openssl comes with MacOSX but it's deprecated by Apple and it's an
> old
> > > > version.  For this reason, many MacOSX users custom install a newer
> > > > openssl and put it in /usr/local/ssl (which, IIRC, is the default
> > > > location for custom openssl installs).
> > > >
> > > > Up through wget 1.16, the following configure flags sufficed to make
> > > > wget's configure script recognize this custom openssl and *use* it:
> > > >
> > > > ./configure --with-ssl=openssl --with-libssl-prefix=/usr/local/ssl
> > > >
> > > > But on wget 1.16.1, those same flags have no effect, and wget is
> built
> > > > against the Mac system openssl in /usr/lib, which is old and
> deprecated.
> > > > Something in the configure script must have changed.
> > > >
> > > > I hope that this is either repaired, or that the README/INSTALL are
> > > > amended to include special instructions on how to force wget to pick
> up
> > > > a custom openssl on MacOSX.
> > > >
> > > > I'm no programmer, but I have a hunch that the same batch of
> pkg-config
> > > > related changes (2014-11-01 in the ChangeLog) that broke pcre
> handling
> > > > on MacOSX (See earlier thread) have broken openssl detection.
> > > >
> > > > I do have pkg-config on my system, in /usr/local.  I have found that
> > > > whether or not I remove pkg-config from my system, I can't get
> openssl
> > > > in /usr/local/ssl to get picked up and used to link with" lines.
> > >
> > > Please try the following:
> > > - make a copy of openssl.pc (the pkg-config file of OpenSSL) into your
> > > wget
> > > directory.
> > > - change the first line 'prefix=...' to 'prefix=/usr/local/ssl'
> > > - try 'PKG_CONFIG_PATH="." ./configure --with-ssl=openssl'
> > >
> > > Later, you may keep your openssl.pc in /usr/local/pkgconfig/, so you
> can
> > > easily find and use it with other projects.
> > >
> > > Please report if this (or similar) works for you.
> > > Of course that has to documented... we simply didn't fall over this
> issue
> > > so
> > > far.
> >
> > OK, that worked, thanks; indeed, all I had to do was
> > 'PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig ./configure blah blah'.
> Easy
> > enough.  (That's the default location for a built-from-source openssl; is
> > openssl not putting its .pc file where it should?)
>
> I guess yes, if you 'make install' your local copy of OpenSSL.
>
> > But that's only half the battle, because that only covers the case where
> > the Mac user has pkg-config installed.  Pkg-config doesn't come with OSX
> or
> > the Apple dev tools.  Up through wget 1.16, the pkgconfigless Mac user
> > could rely on --with-libssl-prefix to point wget to the right place.
>
> Please see the output of ./configure --help.
>

I don't understand.  I did read that.  It says that --with-libssl-prefix
should point to where the desired openssl lives.

If you don't have pkg-config installed, please try the following
> Add "-I/usr/local/ssl/include" to your CFLAGS
>  and add "-L/usr/local/ssl/lib" to your LDFLAGS.
> export both and ./configure.


This worked, thanks.

Cheers,
Charles

Re: [Bug-wget] Wget 1.16.1 detection of non-system openssl broken on MacOSX.

[Charles Diza]

On Thu, Dec 11, 2014 at 4:39 AM, Tim Ruehsen  wrote:

> On Wednesday 10 December 2014 12:02:32 Charles Diza wrote:
> > Wget 1.16.1 has broken detection of non-built-in openssl on MacOSX.
> >
> > Openssl comes with MacOSX but it's deprecated by Apple and it's an old
> > version.  For this reason, many MacOSX users custom install a newer
> > openssl and put it in /usr/local/ssl (which, IIRC, is the default
> > location for custom openssl installs).
> >
> > Up through wget 1.16, the following configure flags sufficed to make
> > wget's configure script recognize this custom openssl and *use* it:
> >
> > ./configure --with-ssl=openssl --with-libssl-prefix=/usr/local/ssl
> >
> > But on wget 1.16.1, those same flags have no effect, and wget is built
> > against the Mac system openssl in /usr/lib, which is old and deprecated.
> > Something in the configure script must have changed.
> >
> > I hope that this is either repaired, or that the README/INSTALL are
> > amended to include special instructions on how to force wget to pick up
> > a custom openssl on MacOSX.
> >
> > I'm no programmer, but I have a hunch that the same batch of pkg-config
> > related changes (2014-11-01 in the ChangeLog) that broke pcre handling
> > on MacOSX (See earlier thread) have broken openssl detection.
> >
> > I do have pkg-config on my system, in /usr/local.  I have found that
> > whether or not I remove pkg-config from my system, I can't get openssl
> > in /usr/local/ssl to get picked up and used to link with" lines.
>
> Please try the following:
> - make a copy of openssl.pc (the pkg-config file of OpenSSL) into your wget
> directory.
> - change the first line 'prefix=...' to 'prefix=/usr/local/ssl'
> - try 'PKG_CONFIG_PATH="." ./configure --with-ssl=openssl'
>
> Later, you may keep your openssl.pc in /usr/local/pkgconfig/, so you can
> easily find and use it with other projects.
>
> Please report if this (or similar) works for you.
> Of course that has to documented... we simply didn't fall over this issue
> so
> far.
>

OK, that worked, thanks; indeed, all I had to do was
'PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig ./configure blah blah'.  Easy
enough.  (That's the default location for a built-from-source openssl; is
openssl not putting its .pc file where it should?)

But that's only half the battle, because that only covers the case where
the Mac user has pkg-config installed.  Pkg-config doesn't come with OSX or
the Apple dev tools.  Up through wget 1.16, the pkgconfigless Mac user
could rely on --with-libssl-prefix to point wget to the right place.

Cheers,
Charles

Re: [Bug-wget] Wget 1.16.1 detection of non-system openssl broken on

[Charles Diza]

On Wed, Dec 10, 2014 at 12:58 PM, Friedrich Haubensak 
wrote:

>
>
> ahh, i observe the same on solaris 10, but did not yet investigate --
> the quicker way to solve this: just change the paths in config.status,
> let run config.status, and then compile :-)
>

I'm not a programmer, so bear with me.  I don't know what "paths" in
config.status you're talking about.  I don't see any paths pertaining to
openssl in there, except for the ones I already passed in via the flags
that aren't being honored.

In any case, I hope that Mac users don't have to perform manual surgery
between the "./configure" and the "make" steps.  The flag
--with-libssl-prefix ought to work out of the box.

Although the presence or absence of pkg-config on my system makes no
difference to the end result---either way, wget is linked against the
system openssl---it *does* affect some of the openssl-related output that
the configure script emits to the terminal.  When I'm back on the relevant
machine, I'll paste the output into an email if that's what the devs want.

Cheers,
Charles

[Bug-wget] Wget 1.16.1 detection of non-system openssl broken on MacOSX.

[Charles Diza]

Wget 1.16.1 has broken detection of non-built-in openssl on MacOSX.

Openssl comes with MacOSX but it's deprecated by Apple and it's an old
version.  For this reason, many MacOSX users custom install a newer
openssl and put it in /usr/local/ssl (which, IIRC, is the default
location for custom openssl installs).

Up through wget 1.16, the following configure flags sufficed to make
wget's configure script recognize this custom openssl and *use* it:

./configure --with-ssl=openssl --with-libssl-prefix=/usr/local/ssl

But on wget 1.16.1, those same flags have no effect, and wget is built
against the Mac system openssl in /usr/lib, which is old and deprecated.
Something in the configure script must have changed.

I hope that this is either repaired, or that the README/INSTALL are
amended to include special instructions on how to force wget to pick up
a custom openssl on MacOSX.

I'm no programmer, but I have a hunch that the same batch of pkg-config
related changes (2014-11-01 in the ChangeLog) that broke pcre handling
on MacOSX (See earlier thread) have broken openssl detection.

I do have pkg-config on my system, in /usr/local.  I have found that
whether or not I remove pkg-config from my system, I can't get openssl
in /usr/local/ssl to get picked up and used to link with" lines.

Cheers,
Charles

Re: [Bug-wget] Wget 1.16.1 won't build on Mac OSX 10.10.1 with Xcode 6.1.1.

[Charles Diza]

On Wed, Dec 10, 2014 at 4:29 AM, Tim Ruehsen  wrote:

> Hi Charles,
>
> I just pushed a commit to the git repo that checks for pcre.h in
> combination
> with pkg-config. If not found, pcre will be automatically disabled.
>
> I attach the patch just in case you don't use git.
>
> Tim
>

I've tested the patch, and it appears to be working.  Thanks. :)

In a previous message you said that I'm missing "headers" for pcre.  This
is the default state of Mac OSX with respect to pcre.  If you install Xcode
and the CommandLine tools, and don't do anything special, you are in the
situation I am in.  In other words, no MacOSX user will have pcre.h, unless
they specifically do something about that.

For that reason, I hope this patch makes it into a release soon.
Otherwise, MacOSX users who did not go through an additional step to
install something (pcre) that is not an advertised dependency, and who want
to build wget 1.16.1, will find that it fails, and they won't know why.

Cheers,
Charles

[Bug-wget] Wget 1.16.1 won't build on Mac OSX 10.10.1 with Xcode 6.1.1.

[Charles Diza]

Wget 1.16.1 refuses to build on OSX 10.10.1, with Xcode 6.1.1.

I've posted the error below; I have never seen it before.  It appears that
wget suddenly requires that pcre be installed.  Is this true?  There was no
mention of it in the latest NEWS file in the tarball.

For the record, my ./configure flags were: ./configure --with-ssl=openssl
--with-libssl-prefix=/usr/local/ssl

-Charles


gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\"
-DLOCALEDIR=\"/usr/local/share/locale\" -I.  -I../lib -I../lib
-I/usr/local/include   -DHAVE_LIBSSL -DNDEBUG  -MT html-url.o -MD -MP -MF
.deps/html-url.Tpo -c -o html-url.o html-url.c
html-url.c:628:33: warning: expression result unused [-Wunused-value]
  mcharset = parse_charset (content);
^~~
./iri.h:59:38: note: expanded from macro 'parse_charset'
#define parse_charset(str)  (str, NULL)
 ^
1 warning generated.
mv -f .deps/html-url.Tpo .deps/html-url.Po
gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\"
-DLOCALEDIR=\"/usr/local/share/locale\" -I.  -I../lib -I../lib
-I/usr/local/include   -DHAVE_LIBSSL -DNDEBUG  -MT http.o -MD -MP -MF
.deps/http.Tpo -c -o http.o http.c
http.c:2657:36: warning: expression result unused [-Wunused-value]
  tmp = parse_charset (tmp2);
   ^~~~
./iri.h:59:38: note: expanded from macro 'parse_charset'
#define parse_charset(str)  (str, NULL)
 ^
1 warning generated.
mv -f .deps/http.Tpo .deps/http.Po
gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\"
-DLOCALEDIR=\"/usr/local/share/locale\" -I.  -I../lib -I../lib
-I/usr/local/include   -DHAVE_LIBSSL -DNDEBUG  -MT init.o -MD -MP -MF
.deps/init.Tpo -c -o init.o init.c
init.c:52:11: fatal error: 'pcre.h' file not found
# include 
  ^
1 error generated.
make[3]: *** [init.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Re: [Bug-wget] post-data works but post-file does not?

[Charles Kozierok]

Yep, that was it. Thanks.

But I guess the bigger question is why a Windows version of wget
wouldn't gracefully handle removal of the standard end-of-line
characters. I'm not even sure I can figure out how to properly write
the data out to the file without the 0A0D at the end.

What's weird is I've used post-file before without this problem. Maybe
the site itself is more "finicky".



On Wed, Sep 22, 2010 at 11:55 AM, Giuseppe Scrivano  wrote:
>
> so we have:
>
> Charles Kozierok  writes:
>
> broken version:
>
>> POST /specifications.aspx HTTP/1.0
>> Referer: http://tmslighting.digiflare.com/specifications.aspx
>> User-Agent: Wget/1.11.4
>> Accept: */*
>> Host: tmslighting.digiflare.com
>> Connection: Keep-Alive
>> Content-Type: application/x-www-form-urlencoded
>> Content-Length: 911
>
>
>
> working version:
>
>> POST /specifications.aspx HTTP/1.0
>> User-Agent: Wget/1.11.4
>> Accept: */*
>> Host: tmslighting.digiflare.com
>> Connection: Keep-Alive
>> Content-Type: application/x-www-form-urlencoded
>> Content-Length: 909
>
>
> I think the file/broken version has a final "\r\n" (end-of-line under
> Windows) that the --post-data versione hasn't.
>
> In fact, you can see the Content-Length difference is 2.
>
> Giuseppe
>

Re: [Bug-wget] post-data works but post-file does not?

[Charles Kozierok]

Sure, here it is. Thanks for your help.

SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\gnuwin32/etc/wgetrc
Setting --output-document (outputdocument) to x.htm
Setting --post-data (postdata) to
__EVENTTARGET=ctl00%24MainContent%24CategoryList&__EVENTARGUMENT=&__LASTFOCUS=&__VIEWSTATE=%2FwEPDwUJMjg0NTkxNjk2D2QWAmYPZBYCAgMPZBYCAgkPZBYCAgUPEA8WBh4NRGF0YVRleHRGaWVsZAUMQ2F0ZWdvcnlOYW1lHg5EYXRhVmFsdWVGaWVsZAUKQ2F0ZWdvcnlJZB4LXyFEYXRhQm91bmRnZBAVERRTZWxlY3QgYSBDYXRlZ29yeS4uLgtBY2Nlc3NvcmllcwdCYWxsYXN0CEJvbGxhcmRzB0NlaWxpbmcGQ3VzdG9tCUxhbmRzY2FwZQhNb3VudGluZwhQZW5kYW50cwVQb2xlcwtRdWljayBTaGlwcwhSZWNlc3NlZA5STE0gUmVmbGVjdG9ycxJSTE0gU2VsZiBCYWxsYXN0ZWQHU2NvbmNlcw5TaWduICYgRGlzcGxheQ9XYWxsIEx1bWluYXJpZXMVEQACMTUCMTMCMTEBMwE1ATcCMTQBMgE4AjE5ATQCMTICMTABMQE5ATYUKwMRZ2dnZ2dnZ2dnZ2dnZ2dnZ2cWAWZkZGfZxViZIyd78D%2BDVfn6TqG%2FfKgk&__EVENTVALIDATION=%2FwEWFALt5MHkBwLhwYzwAQKlh4qyCwKkzdOoCwKrooXFBwKroo3FBwKrorXFBwKpovnGBwKvovnGBwKtovnGBwKroonFBwKqovnGBwK8ovnGBwKrotXGBwKoovnGBwKrorHFBwKrornFBwKrovnGBwKzovnGBwKuovnGB%2FZoZwEfKg3Dhvb9LB635UK9o97G&ctl00%24search_text=search&ctl00%24MainContent%24CategoryList=15
DEBUG output created by Wget 1.11.4 on Windows-MinGW.

--2010-09-22 10:59:19--  http://tmslighting.digiflare.com/specifications.aspx
Resolving tmslighting.digiflare.com... seconds 0.00, 68.178.224.94
Caching tmslighting.digiflare.com => 68.178.224.94
Connecting to tmslighting.digiflare.com|68.178.224.94|:80... seconds
0.00, connected.
Created socket 448.
Releasing 0x005cec28 (new refcount 1).

---request begin---
POST /specifications.aspx HTTP/1.0

User-Agent: Wget/1.11.4

Accept: */*

Host: tmslighting.digiflare.com

Connection: Keep-Alive

Content-Type: application/x-www-form-urlencoded

Content-Length: 909



---request end---
[POST data: 
__EVENTTARGET=ctl00%24MainContent%24CategoryList&__EVENTARGUMENT=&__LASTFOCUS=&__VIEWSTATE=%2FwEPDwUJMjg0NTkxNjk2D2QWAmYPZBYCAgMPZBYCAgkPZBYCAgUPEA8WBh4NRGF0YVRleHRGaWVsZAUMQ2F0ZWdvcnlOYW1lHg5EYXRhVmFsdWVGaWVsZAUKQ2F0ZWdvcnlJZB4LXyFEYXRhQm91bmRnZBAVERRTZWxlY3QgYSBDYXRlZ29yeS4uLgtBY2Nlc3NvcmllcwdCYWxsYXN0CEJvbGxhcmRzB0NlaWxpbmcGQ3VzdG9tCUxhbmRzY2FwZQhNb3VudGluZwhQZW5kYW50cwVQb2xlcwtRdWljayBTaGlwcwhSZWNlc3NlZA5STE0gUmVmbGVjdG9ycxJSTE0gU2VsZiBCYWxsYXN0ZWQHU2NvbmNlcw5TaWduICYgRGlzcGxheQ9XYWxsIEx1bWluYXJpZXMVEQACMTUCMTMCMTEBMwE1ATcCMTQBMgE4AjE5ATQCMTICMTABMQE5ATYUKwMRZ2dnZ2dnZ2dnZ2dnZ2dnZ2cWAWZkZGfZxViZIyd78D%2BDVfn6TqG%2FfKgk&__EVENTVALIDATION=%2FwEWFALt5MHkBwLhwYzwAQKlh4qyCwKkzdOoCwKrooXFBwKroo3FBwKrorXFBwKpovnGBwKvovnGBwKtovnGBwKroonFBwKqovnGBwK8ovnGBwKrotXGBwKoovnGBwKrorHFBwKrornFBwKrovnGBwKzovnGBwKuovnGB%2FZoZwEfKg3Dhvb9LB635UK9o97G&ctl00%24search_text=search&ctl00%24MainContent%24CategoryList=15]
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK

Connection: keep-alive

Date: Wed, 22 Sep 2010 14:59:19 GMT

Server: Microsoft-IIS/6.0

X-Powered-By: PleskWin

X-Powered-By: ASP.NET

X-AspNet-Version: 2.0.50727

Cache-Control: private

Content-Type: text/html; charset=utf-8

Content-Length: 13079



---response end---
200 OK
Registered socket 448 for persistent reuse.
Length: 13079 (13K) [text/html]
Saving to: `x.htm'

 0K .. .. 100% 38.6K=0.3s

2010-09-22 10:59:20 (38.6 KB/s) - `x.htm' saved [13079/13079]

Re: [Bug-wget] post-data works but post-file does not?

[Charles Kozierok]

Estanislao -- I'm on a Windows machine using Gnuwin32 and I can't do
that sort of shell escaping. But I am quite sure it is not the file..
I've recreated it several ways, and I've never had these sorts of
problems before.

Giuseppe, here's the output requested. Thanks.

SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\gnuwin32/etc/wgetrc
Setting --output-document (outputdocument) to x.htm
Setting --referer (referer) to
http://tmslighting.digiflare.com/specifications.aspx
Setting --post-file (postfile) to postdata.txt
DEBUG output created by Wget 1.11.4 on Windows-MinGW.

--2010-09-22 10:22:03--  http://tmslighting.digiflare.com/specifications.aspx
Resolving tmslighting.digiflare.com... seconds 0.00, 68.178.224.94
Caching tmslighting.digiflare.com => 68.178.224.94
Connecting to tmslighting.digiflare.com|68.178.224.94|:80... seconds
0.00, connected.
Created socket 444.
Releasing 0x0033db58 (new refcount 1).

---request begin---
POST /specifications.aspx HTTP/1.0

Referer: http://tmslighting.digiflare.com/specifications.aspx

User-Agent: Wget/1.11.4

Accept: */*

Host: tmslighting.digiflare.com

Connection: Keep-Alive

Content-Type: application/x-www-form-urlencoded

Content-Length: 911



---request end---
[writing POST file postdata.txt ... done]
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 500 Internal Server Error

Connection: keep-alive

Date: Wed, 22 Sep 2010 14:22:03 GMT

Server: Microsoft-IIS/6.0

X-Powered-By: PleskWin

X-Powered-By: ASP.NET

X-AspNet-Version: 2.0.50727

Cache-Control: private

Content-Type: text/html; charset=utf-8

Content-Length: 7763



---response end---
500 Internal Server Error
Registered socket 444 for persistent reuse.
Disabling further reuse of socket 444.
Closed fd 444
2010-09-22 10:22:03 ERROR 500: Internal Server Error.

Re: [Bug-wget] post-data works but post-file does not?

[Charles Kozierok]

Identical, I just copy/pasted from the file to the command line.

Boggle.

On Tue, Sep 21, 2010 at 4:59 PM, Keisial  wrote:
>  Charles Kozierok wrote:
>> Hi,
>>
>> Hoping someone can help me out with this.. I just found a weird case
>> (after banging my head against a wall for a while) where an attempt to
>> do a wget request with a --post-file= directive results in an internal
>> server error, but the identical request with the same (very long) POST
>> string in the command like as --post-data works.
>>
>> This is a problem for other strings that are too long to put in the
>> command line.
>>
>> Any ideas?
>>
>> Best regards,
>>
>> Charles
> Maybe the file version contains something more?
> A trailing new line, a leading BOM, different encoding...
>
>

[Bug-wget] post-data works but post-file does not

[Charles Kozierok]

Hi,

Hoping someone can help me out with this.. I just found a weird case
(after banging my head against a wall for a while) where an attempt to
do a wget request with a --post-file= directive results in an internal
server error, but the identical request with the same (very long) POST
string in the command like as --post-data works.

Any ideas?

Best regards,

Charles

[Bug-wget] post-data works but post-file does not?

[Charles Kozierok]

Hi,

Hoping someone can help me out with this.. I just found a weird case
(after banging my head against a wall for a while) where an attempt to
do a wget request with a --post-file= directive results in an internal
server error, but the identical request with the same (very long) POST
string in the command like as --post-data works.

This is a problem for other strings that are too long to put in the
command line.

Any ideas?

Best regards,

Charles