Re: Curb maximum size of headers
"Tony Lewis" <[EMAIL PROTECTED]> writes: > Hrvoje Niksic wrote: > >> I don't see how and why a web site would generate headers (not >> bodies, to be sure) larger than 64k. > > To be honest, I'm less concerned about the 64K header limit than I > am about limiting a header line to 4096 bytes. The 4k limit does not apply to header lines -- only the 64k limit to the whole header section does. The line length limit is used by the code that reads server output line by line, currently only FTP code reading server responses over control connection. (Directory listings don't count as server responses in this context.) I should have made the *use* of individual limits clearer in the patch commentary. I guess I concentrated too much on the implementation details and forgot that the readers of the list needn't know exactly what code uses fd_read_line for what purpose. > Since you already proposing to limit the entire header to 64K, what > is gained by adding this second limit? I hope this is now clearer; the second limit is used by an entirely separate piece of code. Malicious overlong FTP lines could presumably be exactly as dangerous as malicious HTTP responses. In fact, prior to this patch, something as simple as `nc -lp21 < /dev/zero' brings a connecting Wget, along with the unsuspecting user's system, to its knees. That is just too damn easy, especially with there being a whole bunch of people who check for this kind of bugs, publicizing their findings as security holes. I sincerely wish none of these limits were necessary. If anyone abhors arbitrary limits, it is surely me.
RE: Curb maximum size of headers
Hrvoje Niksic wrote: > I don't see how and why a web site would generate headers (not bodies, to > be sure) larger than 64k. To be honest, I'm less concerned about the 64K header limit than I am about limiting a header line to 4096 bytes. I don't know any sites that send back header lines that long, but they could. Who's to say some site doesn't have a 4K cookie? Since you already proposing to limit the entire header to 64K, what is gained by adding this second limit? Tony
Re: Curb maximum size of headers
"Tony Lewis" <[EMAIL PROTECTED]> writes: > As I said, I think the proposed limits are reasonable, but what if > they are not for a given user mirroring some website? I don't see how and why a web site would generate headers (not bodies, to be sure) larger than 64k. It is highly doubtful that such huge headers would work with other browsers, anyway. In some cases reasonable limits are better than no limits. For example, Wget used to have fancy code to detect circular redirections, and that code could be fooled in a number of ways, causing frantic activity and memory consumption on the client. Now Wget simply refuses to follow more than 20 successive redirections. There is no option to increase that limit, short of editing the source code, but no one has reported a problem with that, because the limit is high enough to never pose a problem in practice. These limits are in the same vein -- they can't be increased because there is never a need to increase them. If I am proven wrong, it is easy enough to add command-line options that control them. > If I understood the patch, wget will refuse to download some files > and the user will have no way to coax it to do so. > > If I missed something, please explain. The only thing you missed is that the scenario you're describing is entirely fictional. If I am wrong about that, please correct me.
download questions
Hello all: Here is the scenario... I am trying to d/l a webpage, but the issue is there are two authentication challenges. The first is from the web server, so I wanted to use something like wget --http-user=user --http-passwd=password http://website.html , once authenticated with the web server the application itself asks for a l/p via post so I found, wget --http-post="login=user&password=pw" http://www.yourclient.com/somepage.html on the gnu site to be an option. Is there a way I can fuse both into one string when logging in to d/l the page? anyhelp would be greatly appreciated. Many thanks, Richard Emanilov [EMAIL PROTECTED]
RE: Curb maximum size of headers
Hrovje Niksic wrote: > Overriding these limits would require *two* new cryptic command-line > options that would clutter the code and documentation and in all likeliness > would never be used, thus bringing no value to the user. As I said, I think the proposed limits are reasonable, but what if they are not for a given user mirroring some website? If I understood the patch, wget will refuse to download some files and the user will have no way to coax it to do so. If I missed something, please explain. Tony
