[Bug-wget] [bug #52705] HTML assets embedding with --page-requisites

2018-11-12 Thread Darshit Shah
Update of bug #52705 (project wget):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[Bug-wget] [bug #52986] Does not compile due to Python

2018-11-12 Thread Darshit Shah
Update of bug #52986 (project wget):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[Bug-wget] [bug #53020] wget -b produces empty wget-log file

2018-11-12 Thread Darshit Shah
Update of bug #53020 (project wget):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[Bug-wget] [bug #53191] wget doesn't unzip data even with an Encoding:gzip header

2018-11-12 Thread Darshit Shah
Update of bug #53191 (project wget):

  Status:None => Needs Discussion   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

This has been fixed in a past update where we changed the default to not
asking for gzip.

There are quite a few issues with various servers behaving differently and so
we need a little time to figure out all these cases

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[Bug-wget] [bug #53322] Add option to let page-requisites bypass no-parent

2018-11-12 Thread Darshit Shah
Update of bug #53322 (project wget):

  Status:None => Invalid
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[Bug-wget] [bug #53750] Regex are ignored with ftp

2018-11-12 Thread Darshit Shah
Update of bug #53750 (project wget):

  Status:   Confirmed => Ready for Merge
 Assigned to:None => darnir 
Operating System:  Mac OS => None   
 Planned Release:None => 1.20   

___

Follow-up Comment #2:

I've sent a patch to the mailing lists that adds this support. It should be
available in the next release.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[Bug-wget] [bug #53818] Proposal: Check HTML suffix (for TEXTHTML flag) also on unchanged files

2018-11-12 Thread Darshit Shah
Update of bug #53818 (project wget):

  Status:None => Inspected  
 Planned Release:None => 1.20   


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[Bug-wget] [bug #54126] Wget keeps crashing in Windows sometimes when the filename is large enough to scroll it

2018-11-12 Thread Darshit Shah
Update of bug #54126 (project wget):

 Assigned to:None => darnir 
 Planned Release:None => 1.21   

___

Follow-up Comment #1:

Thanks for the report! I'll take a look at the issue and see if I can spot any
problems. Seems like this only occurs under Windows, which makes it slightly
problematic when reproducing.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[Bug-wget] [bug #53884] Can wget (and any GNU projects) avoid spitting non-ASCII on the command line???

2018-11-12 Thread Darshit Shah
Update of bug #53884 (project wget):

  Status:None => Invalid
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




Re: [Bug-wget] Filename should end with the first '?' character

2018-11-12 Thread Michael


Hi Tim and all,

Thank you for your reply.

The `--cut-file-get-vars' works fine. This should be the default behavior, or 
people from around the world will curse us for wasting several hours of their 
time on that.

I did not notice effect of `--cut-url-get-vars` effect.


Which brings me to my first 'assignment':

"Be aware that this may have unintended side effects, for example
"image.php?name=sun" will be changed
  to "image.php". The cutting happens before adding the URL to the
download queue."

In the case that "GET image.php?name=sun" return type image/jpeg, the result 
should be downloaded as image_sun.jpg and the proper reference to it should be 
made in the html code.

My initial approach to the wget project was to avoid creating directory to 
every directory GET in WordPress. When the content type returned is html, A 
filename directory.html should be created and proper reference should be in the 
html menu code.

What do you think?

Michael





Re: [Bug-wget] Filename should end with the first '?' character

2018-11-12 Thread Tim Rühsen
Hi Michael,

we have this in Wget2 already

From the docs:

### `--cut-url-get-vars`

  Remove HTTP GET Variables from URLs.
  For example "main.css?v=123" will be changed to "main.css".
  Be aware that this may have unintended side effects, for example
"image.php?name=sun" will be changed
  to "image.php". The cutting happens before adding the URL to the
download queue.


### `--cut-file-get-vars`

  Remove HTTP GET Variables from filenames.
  For example "main.css?v=123" will be changed to "main.css".

  Be aware that this may have unintended side effects, for example
"image.php?name=sun" will be changed
  to "image.php". The cutting happens when saving the file, after
downloading.

  File names obtained from a "Content-Disposition" header are not
affected by this setting (see --content-disposition),
  and can be a solution for this problem.

  When "--trust-server-names" is used, the redirection URL is affected
by this setting.


Regards, Tim

On 11/10/18 10:19 PM, mich...@cyber-dome.com wrote:
> Hello all,
> 
> WordPress has 'invented' a way to avoid caching of static content and force
> downloading it every time. 
> It does so by adding parameters to the file requested. This "feature" is
> slowing the page download and create an issue using wget.
> 
> For example, a stylesheet is appended with "ver" parameter.
> https://condo-farm.com/wp-content/themes/DazChild/style.css?ver=4.8.7
> 
> In wget1 the '?' character was replaced with %3F string (Hex value on the
> character?) and it worked somehow.
> https://condo-farm.com/wp-content/themes/DazChild/style.css%3Fver=4.8.7.css
> 
> The file name generated  was: 
> style.css%3Fver=4.8.7.css and it allowed the website served using HTTP
> server.
> 
> In wget2 the character is not replaced and the generated filename is 
> style.css\?ver\=4.8.7
> 
> This file can't be served using HTTP server as it strips the parameters from
> the filename.
> 
> I suggest to strip the parameter string from the filename and save it as
> "style.css".
> More then that: if the file refers to static content (html,js,css...) I
> suggest stripping the parameter string also in the referring links.
> 
> What do you think?
> 
> Michael
> 
> 



signature.asc
Description: OpenPGP digital signature