bugGNU Wget - Bugs: bug #20378, An accept option based on MIME...

 
 

bug #20378: An accept option based on MIME types

Submitted by:  Micah Cowan <micahcowan>
Submitted on:  Fri 06 Jul 2007 10:56:51 PM UTC  
 
Category: Feature RequestSeverity: 3 - Normal
Priority: 6Status: Awaiting Approval
Privacy: PublicAssigned to: None
Originator Name: Open/Closed: Open
Release: NoneOperating System: None
Reproducibility: NoneFixed Release: None
Planned Release: 1.14Regression: None
Work Required: NonePatch Included: Yes

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 06 Sep 2016 09:03:39 AM UTC, comment #14:

This patch looks great!
it's already four years since it was proposed.
Any idea of why it has not yet been approved?

David Portabella <dportabella>
Thu 02 Jul 2009 10:24:09 PM UTC, comment #13:

(There's also the fact that the current behavior makes --accept useless for filtering out which specific HTML files one wants to download: --accept's not just for filename extensions, after all.)

Micah Cowan <micahcowan>
Thu 02 Jul 2009 09:56:49 PM UTC, comment #12:

I don't see what the point could be for either --accept or --content-type if recursion is off, especially as both options should have no effect whatsoever if recursion is off (''nothing'' should/does prevent downloading explicitly-specified URLs). The existing behavior for --accept can and does cause problems for some users, and is broken anyway since it only looks at filename extensions, and so .htm and .html are traversed without any means of prevention, but .php and .asp are not. But this isn't really the place for this discussion: feel free to take it up on the mailing list (might check the archives for previous discussions)

Micah Cowan <micahcowan>
Thu 02 Jul 2009 09:07:46 PM UTC, comment #11:

Surely thats what the recursive option is for? If recursive is off then I agree that the --content-type option should function as you suggest and only retrieve files that match the content-type, however there is no way that content-types other than HTML, etc.. can be downloaded recursively without recursion of these other content types.

Rich <pomp>
Thu 02 Jul 2009 08:56:12 PM UTC, comment #10:

Actually, that behavior of the --accept option is annoying for many applications, and I'd just as soon not duplicate it. For instance, if what you want is to fetch all the images that are linked from one specific page, --accept still doesn't prevent the wasteful download of all kinds of pages we don't want.

If you really want HTML to be grabbed, then it should be requested IMO. We should have a separate option to fine-tune what gets deleted afterward (or, once we move to a streaming html parser, what never gets saved in the first place). There's already an issue filed for that option, IIRC.

Micah Cowan <micahcowan>
Thu 02 Jul 2009 08:45:05 PM UTC, comment #9:

I've compiled patch file #16272 against the latest wget source but am having problems trying to use wget with the option "--content-type=image*", as you can see from the output:


HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]
Not downloading, content type rejected.

From what I understand, wget isn't able to recursively crawl the website which is HTML to find images to download as the option rejects anything that doesn't match. Should the --content-type option not function in the same was as the --accept option which seems to download HTML files even if rejected but does not save them to disk?

Rich <pomp>
Mon 11 Aug 2008 06:33:42 AM UTC, comment #8:

Attaching new patch which adds some tests. I'm not sure whether I'm using the test system correctly though, and as far as I can see there's no way to verify that it's sending a HEAD request before doing anything else.

(file #16272)

Lars Kotthoff <larsko>
Wed 06 Aug 2008 10:41:03 PM UTC, comment #7:

Should get a suite of tests.

Micah Cowan <micahcowan>
Mon 28 Jul 2008 06:45:19 AM UTC, comment #6:

Attaching new patch which sends a HEAD request first (which turned out be be a trivial change!) and fixes some logging and return code quirks.

(file #16195)

Lars Kotthoff <larsko>
Sat 26 Jul 2008 06:41:03 AM UTC, comment #5:

Ah, understood. This looks a bit hairy though and would be a bigger change. I'll look into it.

Lars Kotthoff <larsko>
Sat 26 Jul 2008 06:29:48 AM UTC, comment #4:

If it wasn't included in the response header to GET, it certainly wouldn't be included in the response to HEAD.

No, I mean it should issue an explicit HEAD to determine the content-type, to determine whether it should then issue a GET. The send_head_first bool var is what controls this, I believe. Currently it sends HEAD first when it needs to do time-stamping, and some situations involving Content-Disposition.

Micah Cowan <micahcowan>
Sat 26 Jul 2008 06:20:15 AM UTC, comment #3:

> Probably needs to send HEAD first, though, to determine the content-type.


From reading the code, my understanding is that it does exactly that. In gethttp it reads the header of the response to figure out how to continue.

Do you mean do an explicit HEAD if the content-type isn't included in the response header?

Lars Kotthoff <larsko>
Sat 26 Jul 2008 05:57:37 AM UTC, comment #2:

Patch looks good. Probably needs to send HEAD first, though, to determine the content-type.

Micah Cowan <micahcowan>
Sat 26 Jul 2008 05:42:46 AM UTC, comment #1:

Attaching patch which adds --content-type=LIST and --content-type-exclude=LIST options which allow to specify MIME type patterns to filter retrieved stuff.

(file #16187)

Lars Kotthoff <larsko>
Fri 06 Jul 2007 10:56:51 PM UTC, original submission:

From TODO:

"Handle MIME types correctly. There should be an option to (not) retrieve files based on MIME types, e.g. `--accept-types=image/*'. This would work for FTP by translating file extensions to MIME types using mime.types."

I'm not convinced we should bother mapping them to file extensions; we already have -A...

Micah Cowan <micahcowan>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #16272:  content-type.patch added by larsko (10KiB - text/x-patch - patch with tests)
file #16195:  content-type.patch added by larsko (6KiB - text/x-patch - Revised patch -- HEAD first, code cleanup)
file #16187:  content-type.patch added by larsko (6KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dportabella (Posted a comment)
  • -unavailable- added by pomp (Posted a comment)
  • -unavailable- added by larsko (Updated the item)
  • -unavailable- added by micahcowan (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 14 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 02 Jul 2009 08:56:12 PM UTCmicahcowanStatusConfirmed=>Awaiting Approval
    Thu 21 Aug 2008 11:32:54 PM UTCmicahcowanPlanned Release1.12=>1.14
    Mon 11 Aug 2008 06:33:42 AM UTClarskoAttached File-=>Added content-type.patch, #16272
    Wed 06 Aug 2008 10:41:03 PM UTCmicahcowanSeverity2 - Minor=>3 - Normal
      Priority5 - Normal=>6
      Planned Release1.15=>1.12
      Work Required0 - Hours=>None
    Mon 28 Jul 2008 06:45:19 AM UTClarskoAttached File-=>Added content-type.patch, #16195
    Sat 26 Jul 2008 05:57:37 AM UTCmicahcowanWork Required1 - Days=>0 - Hours
      Patch IncludedNone=>Yes
    Sat 26 Jul 2008 05:42:46 AM UTClarskoAttached File-=>Added content-type.patch, #16187
    Sun 27 Jan 2008 04:47:24 AM UTCmicahcowanPlanned Release2.0=>1.15
    Sun 12 Aug 2007 11:11:21 PM UTCmnmlCarbon-Copy-=>Added mnml
    Fri 20 Jul 2007 04:56:34 AM UTCmicahcowanPlanned ReleaseNone=>2.0

    Back to the top


    Powered by Savane 3.1-cleanup1