HTTP /1.1 500 Internal Server Error
I am having trouble wgetting a samsung printer driver from their site. Every time I try, I immediately get an HTTP/1.1 500 Internal Server Error. The web browser initiates the download properly when I click on the link from the referer page. Here is the command I am running (I don't have a .wgetrc): wget --debug --referer=http://www.samsungelectronics.com/printer/support/downloads/400329_844_file4.html; http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzamp;realname=spp-1.0.2.i386.tar.gz; and here is the debug output: DEBUG output created by Wget 1.8.1 on linux-gnu. --08:21:58-- http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzamp;realname=spp-1.0.2.i386.tar.gz = `Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzamp;realname=spp-1.0.2.i386.tar.gz' Connecting to 211.45.27.253:80... connected. Created socket 3. Releasing 0x8071fe0 (new refcount 0). Deleting unused 0x8071fe0. ---request begin--- GET /servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzamp;realname=spp-1.0.2.i386.tar.gz HTTP/1.0 User-Agent: Wget/1.8.1 Host: 211.45.27.253 Accept: */* Connection: Keep-Alive Referer: http://www.samsungelectronics.com/printer/support/downloads/400329_844_file4.html ---request end--- HTTP request sent, awaiting response... HTTP/1.1 500 Internal Server Error Server: Microsoft-IIS/5.0 Date: Sun, 02 Jun 2002 12:07:47 GMT Connection: keep-alive Connection: Keep-alive Content-Type: text/html Content-Length: 1565 Registered fd 3 for persistent reuse. Closing fd 3 Releasing 0x8072818 (new refcount 0). Deleting unused 0x8072818. Invalidating fd 3 from further reuse. 08:21:59 ERROR 500: Internal Server Error. Thanks for a great tool! Mark
Re: HTTP /1.1 500 Internal Server Error
Mark Bucciarelli wrote:
I am having trouble wgetting a samsung printer driver from their site. Every
time I try, I immediately get an HTTP/1.1 500 Internal Server Error. The
web browser initiates the download properly when I click on the link from the
referer page.
Here is the command I am running (I don't have a .wgetrc):
wget --debug
--referer=http://www.samsungelectronics.com/printer/support/downloads/400329_844_file4.html;
http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzamp;realname=spp-1.0.2.i386.tar.gz;
and here is the debug output:
debug output skipped/
This seems to be yet another encoding problem. I have no problem if I
change the 'amp;' to ''. IIRC URLs found in a HTML page should be HTML
decoded. A simple test (wget -F -i URL.html) shows that wget does this.
But I'm not sure wget should do it for URLs on the cmd line or in a
non-HTML file. In the past we had a lot of problems with wget being
overzealously {en|de}coding URLs.
$ wget
http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzrealname=spp-1.0.2.i386.tar.gz;
--15:20:35--
http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzrealname=spp-1.0.2.i386.tar.gz
=
`Downloader@path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzrealname=spp-1.0.2.i386.tar.gz'
Connecting to 211.45.27.253:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28,864,218 [application/octet-stream]
Last-modified header missing -- time-stamps turned off.
--15:20:36--
http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzrealname=spp-1.0.2.i386.tar.gz
=
`Downloader@path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gzrealname=spp-1.0.2.i386.tar.gz'
Connecting to 211.45.27.253:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/octet-stream]
[ = ] 1,257,472 25.53K/s
Thanks for a great tool!
And thank you for reading the instructions and actually including debug
output !
Mark
--
Med venlig hilsen / Kind regards
Hack Kampbjørn
Patch for recovering from proxy failure
I have posted a patch to help recover from proxy failures where the proxy adds a HTML document with error message to aborted download now twice to wget-patches. There has been no reaction of any kind. Could someone tell me what is happening? Am I doing something so wrong it deserves no reply? The patch should be available from [EMAIL PROTECTED] or http://kotisivu.mtv3.fi/oma/marko.kohtala/wget-continue.patch and ChangeLog from http://kotisivu.mtv3.fi/oma/marko.kohtala/wget-continue-changelog.patch -- Marko Kohtala Maksuton sähköposti aina käytössä http://luukku.com Kuukausimaksuton MTV3 Internet-liittymä www.mtv3.fi/liittyma
Re: Wget 1.8.2-pre3 ready for testing
On Tue, 28 May 2002, Hrvoje Niksic wrote:
Doug Kaufman [EMAIL PROTECTED] writes:
This doesn't work out of the box for DJGPP or for Cygwin. Appended
is a patch to fix most of the problems.
Thanks for the comments and the patch. The patch will most likely not
make into the 1.8.2 release.
I didn't really expect it to go into a near-final release.
Patching configure is a bad idea, as that file is auto-generated.
Patches should go either to configure.in, or Autoconf should be fixed.
The patch for Cygwin worked, but really wasn't the appropriate fix.
Appended is a revised patch, against the 1.8.2 release. I also
included the DJGPP fix for .netrc, which I forgot in the first patch.
This was tested using configure generated by autoconf from the patched
configure.in.
As for the DJGPP support such as `msdosify', I'm really not sure
whether that should go in. I certainly don't want to support the
broken 8+3 file systems. It's just too painful, and DOS isn't all
that used anymore.
I am not sure that I follow the reasoning here. DOS is alive and well
with almost all GNU programs ported to DOS and most compiling under
DOS from the main GNU source code. Once bash and gcc were ported, all
the rest followed. Do you really want wget to be one of the few GNU
programs which don't support the DOS operating system with the GCC
compiler? The algorithms for adjusting filenames to 8+3 were worked
out years ago. As noted in the patch, I just borrowed this code from
the DOS port of GNU tar. Networking code had been a problem, but with
watt-32 development this has been much easier the last few years.
As the main person distributing the DOS binary for the lynx browser,
I can assure you (from the downloads and from requests for assistance
that I receive), that there are still lots of DOS users out there
looking for software to use over the net. Some are visually impaired
and some are from parts of the world that can't afford newer desktop
computers. Others just prefer the DOS operating system.
Doug
--- wget-1.8.2/configure.in.orig2002-05-17 19:05:10.0 -0800
+++ wget-1.8.2/configure.in 2002-06-01 05:41:02.0 -0800
@@ -138,6 +138,7 @@
dnl Might also be erelevant for DJGPP.
dnl
case $host_os in
+ *msdosdjgpp) exeext='.exe';;
*win32) exeext='.exe';;
*) exeext='';;
esac
--- wget-1.8.2/djconfig.sh.orig 2002-06-01 05:21:22.0 -0800
+++ wget-1.8.2/djconfig.sh 2002-06-01 05:21:22.0 -0800
@@ -0,0 +1,15 @@
+#!/bin/sh
+# This file, when run from a bash shell in DOS, will configure wget
+# for DJGPP. Be sure to set the environment variable WATT_ROOT first,
+# pointing to your WATT-32 distribution. Remove -lintl and -liconv
+# if you don't have the gettext package installed. Remove -lwmemu if
+# you don't want to link with the wmemu floating point emulator. Remove
+# --with-ssl if you don't have openssl installed. This file must have
+# unix-style end of lines (LF), not DOS-style (CR LF).
+
+auto_cflags=1 \
+CFLAGS=-W \
+CPPFLAGS=-I$WATT_ROOT/inc \
+LIBS=-L$WATT_ROOT/lib -lwatt -lintl -liconv -lwmemu \
+./configure \
+--with-ssl
--- wget-1.8.2/Makefile.in.orig 2002-05-17 19:05:10.0 -0800
+++ wget-1.8.2/Makefile.in 2002-06-01 05:21:22.0 -0800
@@ -153,7 +153,7 @@
$(RM) *~ *.bak $(DISTNAME).tar.gz
distclean-top: clean-top
- $(RM) Makefile config.status config.log config.cache stamp-h
+ $(RM) Makefile config.status config.log config.cache libtool stamp-h
realclean-top: distclean-top
$(RM) configure
--- wget-1.8.2/src/config.h.in.orig 2002-05-17 19:05:14.0 -0800
+++ wget-1.8.2/src/config.h.in 2002-06-01 05:24:28.0 -0800
@@ -36,7 +36,9 @@
/* AIX requires this to be the first thing in the file. */
#ifdef __GNUC__
+#ifndef __CYGWIN__
# define alloca __builtin_alloca
+#endif /* __CYGWIN__ */
#else
# if HAVE_ALLOCA_H
# include alloca.h
--- wget-1.8.2/src/ftp.c.orig 2002-05-17 19:05:16.0 -0800
+++ wget-1.8.2/src/ftp.c2002-06-01 05:21:24.0 -0800
@@ -43,6 +43,9 @@
#include sys/types.h
#include assert.h
#include errno.h
+#ifdef __DJGPP__
+#include sys/errno.h
+#endif /* __DJGPP__ */
#include wget.h
#include utils.h
@@ -1352,7 +1355,7 @@
follow them. */
if (!opt.retr_symlinks)
{
-#ifdef HAVE_SYMLINK
+#if defined(HAVE_SYMLINK) defined(S_IFLNK)
if (!f-linkto)
logputs (LOG_NOTQUIET,
_(Invalid name of the symlink, skipping.\n));
@@ -1393,7 +1396,7 @@
logprintf (LOG_NOTQUIET,
_(Symlinks not supported, skipping symlink `%s'.\n),
con-target);
-#endif /* not HAVE_SYMLINK */
+#endif /* not HAVE_SYMLINK or not S_IFLNK */
}
else/* opt.retr_symlinks */
{
--- wget-1.8.2/src/gen_sslfunc.c.orig 2002-05-17 19:14:48.0 -0800
+++
Bug ?
Dear [EMAIL PROTECTED], Please pardon the sudden e-mail. My name is Sekigawa. I am a Network SE in Japan. Only a few days ago, I installed wget-1.8.2 and running on Solaris2.6. But wget-1.8.2 dumped core file before connection. See also below, -- --13:30:45-- http://fly.cc.fer.hr:80/ $B"M(B'index.html' Segmentation Falut(Core Dump) -- When it was running "./configure", it showed WARNING message about gcc version on Solaris System. I tried to install and run other wget version (1.7, 1.6), in addition, to do wget-1.8.1-sol26-sparc-local.gz. Every wget versions dumped core file before connection! Environment related to gcc etc on my Solaris2.6 System is so wrong ??? or what, Is this wget's bug ??? Please let me know, when you get time. I would greately appreciate any help you could give me. 2002/06/03 Best Regards, Sekigawa Ai __ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/
Re: HTTP /1.1 500 Internal Server Error
Hack Kampbjørn [EMAIL PROTECTED] writes: But I'm not sure wget should do [HTML de-quoting] for URLs on the cmd line or in a non-HTML file. I'm pretty sure that it shouldn't. HTML unquoting only makes sense in the context of HTML. That's how the browsers behave, as well -- typing amp; in the location field will not cause it to be dequoted.
Re: Bug ?
I don't know why Wget dumps core on startup. Perhaps a gettext problem? I have seen reports of failure on startup on Solaris, and it strikes me that Wget could have picked up wrong or inconsistent gettext. Try unsetting the locale-related evnironment variables and seeing if Wget works then.
Re: wget 1.8.1 problem.
This crash seems to be gettext-related. What does `ldd wget' say?
Re: http://bugs.debian.org/148583 Internationalization isincomplete - only translation provided
Noel Koethe [EMAIL PROTECTED] writes: The internationalization of wget seem incomplete. It is translated, but not properly localized, which can easily be seen here: Längd: 34,885,632 [audio/mpeg] 100%[] 34,885,632 True. I intended the thousand separator to be a simple visual aid; I didn't even think about the proper separators and how this should be done in different locales. Most of Wget avoids the localization issues by using ISO 8601-like formats for dates, and sticking to the C locale when printing numbers. So far noone has complained. At the risk of sounding the wrong way, I'd like to ask: is this really so much of a problem? Are other command-line programs using thousands separators, and doing it correctly, so that Wget stands apart? I'd really like the basic output of numbers not to depend on the locale -- if such a thing is acceptable.
[WINDOWS] Missing DLL error
When I run wget 1.8.2 (with just -V) I get a message stating that LIBAY32.DLL cannot be found (wget 1.8.1 is OK). -- Gianfranco Boggio-Togna Milano (Italy)
