[Bug-wget] Wget 1.16.3 v. VMS

I don't know how long this has been true, but I recently noticed that some recursive HTTP fetch operations were failing (on VMS) because the URLs contained a "?", and the code in src/url.c (et al.) thought that this was a problem in file names on only Windows. For example (1.16.3): ALP $ wgo -

[Bug-wget] [bug #44674] Add an option that will send the HTTP request to stderr or a file

Follow-up Comment #6, bug #44674 (project wget): Also --debug doesn't show full FORM bodies. ___ Reply to this item at: ___ Message sent via/by Savannah

[Bug-wget] [Patch] fix bug #44628 not honoring RFC 6266 in --content-disposition

The problem was that parse_content_disposition treated the values "filename" and "filename*" as the same and concatenated both values. RFC 6266 states that if both are present, "filename*" should have preference. Now, the patch is tricky, because in this case: attachment; filename*="A.ext"; filen

[Bug-wget] [bug #44674] Add an option that will send the HTTP request to stderr or a file

Follow-up Comment #5, bug #44674 (project wget): Tim: OK please somebody be sure that example is given nearby the --debug option section of the man page. Also it would be good if there was a built-in way to do it in case it is inconvenient to install other programs or do extra input output job st

Re: [Bug-wget] Incorrect handling of Cyrillic characters in http request - any workaround?

On 01/04/15 00:16, Stephen Wells wrote: Hi Tim, Sorry for the ambiguity. To be more specific, the file name is fine: in the shell script the file name $*.mp3 expands correctly to e.g. мазать.mp3 . The audio within the file consists of the Google robot voice reading the string of percent-escaped

Re: [Bug-wget] Incorrect handling of Cyrillic characters in http request - any workaround?

THANK YOU Random Coder! That did the trick. Apparently my earlier attempts were unsuccessful because the problem I was trying to solve was not the problem I actually had :) Specifically I went to whatsmyuseragent.com and my browser id'd as "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (K

Re: [Bug-wget] Incorrect handling of Cyrillic characters in http request - any workaround?

Hi Tim, Sorry for the ambiguity. To be more specific, the file name is fine: in the shell script the file name $*.mp3 expands correctly to e.g. мазать.mp3 . The audio within the file consists of the Google robot voice reading the string of percent-escaped characters literally, not reading the Russ

[Bug-wget] [bug #44674] Add an option that will send the HTTP request to stderr or a file

Follow-up Comment #4, bug #44674 (project wget): You can use the --debug flag to show the HTTP request and response headers, including when the traffic is encrypted with SSL. ___ Reply to this item at:

Re: [Bug-wget] Incorrect handling of Cyrillic characters in http request - any workaround?

On Tue, Mar 31, 2015 at 10:11 AM, Stephen Wells wrote: > Dear all - I am currently trying to use wget to obtain mp3 files from the > Google Translate TTS system. In principle this can be done using: > > wget -U Mozilla -O "${string}.mp3" " > http://translate.google.com/translate_tts?tl=TL&q=${stri

Re: [Bug-wget] Incorrect handling of Cyrillic characters in http request - any workaround?

Hi Steven, Am Dienstag, 31. März 2015, 18:11:58 schrieb Stephen Wells: > Dear all - I am currently trying to use wget to obtain mp3 files from the > Google Translate TTS system. In principle this can be done using: > > wget -U Mozilla -O "${string}.mp3" " > http://translate.google.com/translate_t

[Bug-wget] Incorrect handling of Cyrillic characters in http request - any workaround?

Dear all - I am currently trying to use wget to obtain mp3 files from the Google Translate TTS system. In principle this can be done using: wget -U Mozilla -O "${string}.mp3" " http://translate.google.com/translate_tts?tl=TL&q=${string}"; where TL is a twoletter language code (en,fr,de and so on)

Re: [Bug-wget] gethttp cleanup

Hi Hubert, Hubert Tarasiuk writes: > I have identified a potential drawback with the function > `establish_connection`. > > [Patch #3] > On error, it would free the `req` variable, but it never zeroed > `*req_ref`. As the matter of fact, it only wrote to `req_ref` on > successful exit (when it d

[Bug-wget] [bug #44674] Add an option that will send the HTTP request to stderr or a file

Follow-up Comment #3, bug #44674 (project wget): Just open a second console and start nc -l -p Start wget in your first console http_proxy=localhost: wget http://www.example.com nc will now dump everything that Wget sends. You could even generate an answer (e.g. with copy & paste).