Re: HTTP 1.1?

2006-02-21 Thread Hrvoje Niksic
Dan Jacobson <[EMAIL PROTECTED]> writes:

> The documents don't say how or why one can/not force wget to send
> HTTP 1.1 headers, instead of 1.0. Maybe it is simply not ready yet?

It's not.  The missing piece is the "chunked" transfer mode.


HTTP 1.1?

2006-02-21 Thread Dan Jacobson
The documents don't say how or why one can/not force wget to send
HTTP 1.1 headers, instead of 1.0. Maybe it is simply not ready yet?


Re: HTTP /1.1 500 Internal Server Error

2002-06-03 Thread Mark Bucciarelli

On Sunday 02 June 2002 09:38 am, Hack Kampbjørn wrote:
> 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.
[snip]
> This seems to be yet another encoding problem. I have no problem if I
> change the '&' 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.

Thanks, I was able to get this to work.

I think the man page should mention this coding/decoding stuff.  Not important 
enough for the description, but perhaps you could add the following paragraph 
under the -F option:

If the URL includes a character entity reference (that is, < > &
or "), the -F option will automatically decode these references.  If
you not using the -F option, then you should replace the references with
the characters themselves (that is, <, >, &, or ").

Mark






Re: HTTP /1.1 500 Internal Server Error

2002-06-02 Thread Hrvoje Niksic

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 "&" in the location field will not cause it to be dequoted.



Re: HTTP /1.1 500 Internal Server Error

2002-06-02 Thread Hack Kampbjørn

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.gz&realname=spp-1.0.2.i386.tar.gz";
> 
> and here is the debug output:


This seems to be yet another encoding problem. I have no problem if I
change the '&' 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.gz&realname=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.gz&realname=spp-1.0.2.i386.tar.gz
   =>
`Downloader@path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=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.gz&realname=spp-1.0.2.i386.tar.gz
   =>
`Downloader@path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=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



HTTP /1.1 500 Internal Server Error

2002-06-02 Thread Mark Bucciarelli

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.gz&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.gz&realname=spp-1.0.2.i386.tar.gz
   => 
`Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&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.gz&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




Help Using HTTP 1.1

2002-05-20 Thread Raahul Kumar

I wanted to use your basic authentication/proxy handling code. I do not need
the SSL stuff. I want some advice on how to get rid of all the surplus headers.
There is no need for stuff like SSL timestamps etc.

I'm a developer for Freeciv(www.freeciv.org), and we're GPLed as well, so there
won't be any problems. If there any alternative libraries handling HTTP 1.1
references that would be better to use, please let me know.

Aloha,
RK.

You did something because it had always been done, and the explanation was,
"but we've always done it this way." A million dead people can't have been
wrong, can they?
{The Fifth Elephant, 1999, Terry Pratchett}

__
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com



Re: HTTP 1.1

2002-04-15 Thread Hrvoje Niksic

[EMAIL PROTECTED] writes:

>>Csaba Raduly's patch would break Wget because it doesn't suppose the
>>"chunked" transfer-encoding.  Also, its understanding of persistent
>>connection might not be compliant with HTTP/1.1.
>
> IT WAS A JOKE !

I know that.  But someone not acquainted with HTTP might not
understand why the patch doesn't work, especially with Wget seemingly
using a lot of HTTP/1.1 features.  That is why I felt compelled to
explain the joke, despite what experience taught me about explaining
jokes.  :-)

> Serves me right. I need to put bigger smilies :-(

Don't worry; jokes without smilies are usually the best ones.



Re: HTTP 1.1

2002-04-15 Thread csaba . raduly


On 12/04/2002 21:37:31 hniksic wrote:

>"Tony Lewis" <[EMAIL PROTECTED]> writes:
>
>> Hrvoje Niksic wrote:
>>
>>> > Is there any way to make Wget use HTTP/1.1 ?
>>>
>>> Unfortunately, no.
>>
>> In looking at the debug output, it appears to me that wget is really
>> sending HTTP/1.1 headers, but claiming that they are HTTP/1.0
>> headers. For example, the Host header was not defined in RFC 1945,
>> but wget is sending it.
>
>Yes.  That is by design -- HTTP was meant to be extended in that way.
>Wget is also requesting and accepting `Keep-Alive', using `Range', and
>so on.
>
>Csaba Raduly's patch would break Wget because it doesn't suppose the
>"chunked" transfer-encoding.  Also, its understanding of persistent
>connection might not be compliant with HTTP/1.1.

IT WAS A JOKE !
Serves me right. I need to put bigger smilies :-(


--
Csaba Ráduly, Software Engineer   Sophos Anti-Virus
email: [EMAIL PROTECTED]http://www.sophos.com
US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933




Re: HTTP 1.1

2002-04-12 Thread Hrvoje Niksic

"Tony Lewis" <[EMAIL PROTECTED]> writes:

> Hrvoje Niksic wrote:
>
>> > Is there any way to make Wget use HTTP/1.1 ?
>>
>> Unfortunately, no.
>
> In looking at the debug output, it appears to me that wget is really
> sending HTTP/1.1 headers, but claiming that they are HTTP/1.0
> headers. For example, the Host header was not defined in RFC 1945,
> but wget is sending it.

Yes.  That is by design -- HTTP was meant to be extended in that way.
Wget is also requesting and accepting `Keep-Alive', using `Range', and
so on.

Csaba Raduly's patch would break Wget because it doesn't suppose the
"chunked" transfer-encoding.  Also, its understanding of persistent
connection might not be compliant with HTTP/1.1.



Re: HTTP 1.1

2002-04-12 Thread Ian Abbott

On 12 Apr 2002 at 11:59, Tony Lewis wrote:

> Hrvoje Niksic wrote:
> 
> > > Is there any way to make Wget use HTTP/1.1 ?
> >
> > Unfortunately, no.
> 
> In looking at the debug output, it appears to me that wget is really sending
> HTTP/1.1 headers, but claiming that they are HTTP/1.0 headers. For example,
> the Host header was not defined in RFC 1945, but wget is sending it.

It's allowed to send these additional headers as a server would
just ignore those it doesn't understand.  Wget does not fulfill the
minimal requirements of an HTTP/1.1 client, which is why it does
not pretend to be one!  Maybe one day



RE: HTTP 1.1

2002-04-12 Thread Ian Abbott

On 12 Apr 2002 at 21:41, Boaz Yahav wrote:

> So basically I only need to make this change and recompile?
> I wish this was a switch :)

No, it just lies to the server.  Wget is not really an HTTP/1.1
client and may go up in smoke if the server thinks it is!
(Hopefully it contains enough extinguisher to prevent a major fire,
but regardless, the result would not be as intended. ^_^)



Re: HTTP 1.1

2002-04-12 Thread Tony Lewis

Hrvoje Niksic wrote:

> > Is there any way to make Wget use HTTP/1.1 ?
>
> Unfortunately, no.

In looking at the debug output, it appears to me that wget is really sending
HTTP/1.1 headers, but claiming that they are HTTP/1.0 headers. For example,
the Host header was not defined in RFC 1945, but wget is sending it.

Tony




RE: HTTP 1.1

2002-04-12 Thread Boaz Yahav

So basically I only need to make this change and recompile?
I wish this was a switch :)

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 12, 2002 12:58 PM
Cc: Boaz Yahav; [EMAIL PROTECTED]
Subject: Re: HTTP 1.1



On 11/04/2002 18:26:15 hniksic wrote:

>"Boaz Yahav" <[EMAIL PROTECTED]> writes:
>
>> Is there any way to make Wget use HTTP/1.1 ?
>
>Unfortunately, no.

Sure it can be made to use HTTP 1.1

--- http.c.orig   Wed Jan 30 14:10:42 2002
+++ http.c  Fri Apr 12 11:56:22 2002
@@ -838,7 +838,7 @@
  + 64);
   /* Construct the request.  */
   sprintf (request, "\
-%s %s HTTP/1.0\r\n\
+%s %s HTTP/1.1\r\n\
 User-Agent: %s\r\n\
 Host: %s%s%s%s\r\n\
 Accept: %s\r\n\




:-)

--
Csaba Ráduly, Software Engineer   Sophos
Anti-Virus
email: [EMAIL PROTECTED]
http://www.sophos.com
US Support: +1 888 SOPHOS 9 UK Support: +44 1235
559933




Re: HTTP 1.1

2002-04-12 Thread csaba . raduly


On 11/04/2002 18:26:15 hniksic wrote:

>"Boaz Yahav" <[EMAIL PROTECTED]> writes:
>
>> Is there any way to make Wget use HTTP/1.1 ?
>
>Unfortunately, no.

Sure it can be made to use HTTP 1.1

--- http.c.orig   Wed Jan 30 14:10:42 2002
+++ http.c  Fri Apr 12 11:56:22 2002
@@ -838,7 +838,7 @@
  + 64);
   /* Construct the request.  */
   sprintf (request, "\
-%s %s HTTP/1.0\r\n\
+%s %s HTTP/1.1\r\n\
 User-Agent: %s\r\n\
 Host: %s%s%s%s\r\n\
 Accept: %s\r\n\




:-)

--
Csaba Ráduly, Software Engineer   Sophos Anti-Virus
email: [EMAIL PROTECTED]http://www.sophos.com
US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933




Re: HTTP 1.1

2002-04-11 Thread Hrvoje Niksic

"Boaz Yahav" <[EMAIL PROTECTED]> writes:

> Is there any way to make Wget use HTTP/1.1 ?

Unfortunately, no.



HTTP 1.1

2002-02-24 Thread Boaz Yahav



Hi
 
Is there any way to make Wget 
use HTTP/1.1 ?
 
Thanks
 
berber
 


HTTP/1.1 (was Re: timestamping content-length --ignore-length)

2002-02-01 Thread Ian Abbott

On 1 Feb 2002 at 8:17, Daniel Stenberg wrote:

> You may count this mail as advocating for HTTP 1.1 support, yes! ;-)

I did write down some minimal requirements for HTTP/1.1 support on
a scrap of paper recently. It's probably still buried under the
more recent strata of crap on my desk somewhere! I know chunked
encoding support was one of the requirements, but I can't remember
any others I wrote down. It was probably an incomplete list anyway!

HTTP/1.1 support would also allow gzip and deflate encodings etc.
to be added as configurable options later.

Once HTTP/1.1 support was working reliably, it ought to be made the
default, with command-line or .wgetrc options to fall back to
sending HTTP/1.0 requests.