Closed Bug 249508 Opened 21 years ago Closed 19 years ago

Wrong GET PATH when saving Website

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8.1

People

(Reporter: rasche, Assigned: Biesinger)

References

Details

(Keywords: fixed1.8.1)

Attachments

(2 files)

possible patch
4.46 KB, patch
bzbarsky
: review+
jst
: superreview+
asa
: approval1.8a6+
Details | Diff | Splinter Review
also fix input type="image"
1.03 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
bzbarsky
: approval-branch-1.8.1+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040210 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040210 Firefox/0.8 Hi All! I saw this 404 codes in my Web server logs which seem to come from Firefox saving Web sites. - - [13/Mar/2004:08:26:09 +0100] "GET /old_files/ HTTP/1.1" 404 275 "-" "Mozilla/4.75 [en] (X11, U; Nessus)" - - [21/Jun/2004:03:39:33 +0200] "GET /b/black/wonderful%20life%20(black)_files/black_wonderfullife.jpg HTTP/1.1" 404 331 "http://favorite-lyrics.com/b/black/black_wonderfullife_wonderfullife.html" "Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)" - - [21/Jun/2004:07:04:14 +0200] "GET /b/black/black_wonderfullife_wonderfullife_files/black_wonderfullife.jpg HTTP/1.1" 404 342 "http://favorite-lyrics.com/b/black/black_wonderfullife_wonderfullife.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" - - [21/Jun/2004:07:04:14 +0200] "GET /b/black/black_wonderfullife_wonderfullife_files/dummy.gif HTTP/1.1" 404 328 "http://favorite-lyrics.com/b/black/black_wonderfullife_wonderfullife.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" - - [21/Jun/2004:07:04:14 +0200] "GET /b/black/black_wonderfullife_wonderfullife_files/flyback.gif HTTP/1.1" 404 330 "http://favorite-lyrics.com/b/black/black_wonderfullife_wonderfullife.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" - - [21/Jun/2004:07:04:14 +0200] "GET /b/black/black_wonderfullife_wonderfullife_files/flyhome.gif HTTP/1.1" 404 330 "http://favorite-lyrics.com/b/black/black_wonderfullife_wonderfullife.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" - - [21/Jun/2004:07:04:14 +0200] "GET /b/black/black_wonderfullife_wonderfullife_files/flytop.gif HTTP/1.1" 404 329 "http://favorite-lyrics.com/b/black/black_wonderfullife_wonderfullife.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" - - [21/Jun/2004:07:04:14 +0200] "GET /b/black/black_wonderfullife_wonderfullife_files/awstats_misc_tracker_002.js HTTP/1.1" 404 346 "http://favorite-lyrics.com/b/black/black_wonderfullife_wonderfullife.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" - - [01/Jul/2004:06:58:51 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung_files/alphaville_foreveryoung.jpg HTTP/1.1" 404 354 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113" - - [01/Jul/2004:06:58:51 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung_files/dummy.gif HTTP/1.1" 404 336 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113" The schema is a wrong GET validurl underscore _files/ which makes it nonvalid aka 404. Thank you in advance! Regards, Jan Reproducible: Always Steps to Reproduce: 1. tail -f accees.log under Apache 2 2. Save a Web site with FireFox under GNU/Linux Actual Results: 404
also mentioned in bug 216818 comment 4
Assignee: general → darin
Component: Browser-General → Networking: HTTP
QA Contact: general → core.networking.http
what was the url that was successfully saved? (i.e. the 200 OK one before those 404...) (I don't think this is a bug in networking, more likely to be webbrowserpersist)
80.133.242.254 - - [02/Jul/2004:19:15:45 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung.html HTTP/1.1" 200 14299 "http://favorite-lyrics.com/a/alphaville/alphaville.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:45 +0200] "GET /styles.css HTTP/1.1" 200 4653 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:45 +0200] "GET /library/ns4background.js HTTP/1.1" 200 426 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:45 +0200] "GET /library/automate.js HTTP/1.1" 200 821 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:46 +0200] "GET /share/wallblue.jpg HTTP/1.1" 200 11971 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:46 +0200] "GET /images/alphaville_foreveryoung.jpg HTTP/1.1" 200 29549 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:46 +0200] "GET /share/dummy.gif HTTP/1.1" 200 49 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:46 +0200] "GET /share/flyback.gif HTTP/1.1" 200 1312 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:46 +0200] "GET /images/alphaville_afternoonsinutopia.gif HTTP/1.1" 200 102844 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:47 +0200] "GET /share/flyhome.gif HTTP/1.1" 200 555 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:15:47 +0200] "GET /share/flytop.gif HTTP/1.1" 200 467 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" #->Save Page As... #->File name: alphaville_foreveryoung_foreveryoung.html #->Files of type: Web Page Complete (*htm, *html) 80.133.242.254 - - [02/Jul/2004:19:16:09 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung_files/alphaville_foreveryoung.jpg HTTP/1.1" 404 354 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:16:09 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung_files/dummy.gif HTTP/1.1" 404 336 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:16:09 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung_files/alphaville_afternoonsinutopia.gif HTTP/1.1" 404 360 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:16:09 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung_files/flyback.gif HTTP/1.1" 404 338 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:16:09 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung_files/flyhome.gif HTTP/1.1" 404 338 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 80.133.242.254 - - [02/Jul/2004:19:16:09 +0200] "GET /a/alphaville/alphaville_foreveryoung_foreveryoung_files/flytop.gif HTTP/1.1" 404 337 "http://favorite-lyrics.com/a/alphaville/alphaville_foreveryoung_foreveryoung.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8"
Assignee: darin → cbiesinger
Bug 269447 (windows) looks similiar
*** Bug 273116 has been marked as a duplicate of this bug. ***
ok, unrelated to proxies. this bug is caused by webbrowserpersist setting the src attribute on an image node to "..._files/...", in order to serialize that presumably. but this triggers an image load from the network. (via nsImageLoadingContent::ImageURIChanged) still investigating where that node comes from and why it's expected to work...
OK... so it clones the node before modifying the attributes on it... (nsWebBrowserPersist::GetNodeToFixup, where nsEncoderNodeFixup::FixupNode ends up eventually)
Status: UNCONFIRMED → NEW
Component: Networking: HTTP → File Handling
Ever confirmed: true
OS: Linux → All
QA Contact: core.networking.http → ian
Hardware: PC → All
Target Milestone: --- → mozilla1.8alpha6
No longer blocks: 269447
*** Bug 269447 has been marked as a duplicate of this bug. ***
No longer blocks: 269882
*** Bug 269882 has been marked as a duplicate of this bug. ***
Attached patch possible patch — — Splinter Review
well, this fixes the bug... I suspect this works for other content (scripts, style sheets, etc) because cloneNode does not set the document of the node, and these nodes only load stuff when not in a document... bz/jst, is that correct? and if it's not, why does this only seem to affect images?
Attachment #169138 - Flags: superreview?(jst)
Attachment #169138 - Flags: review?(bzbarsky)
oh, the relevant part of that patch is of course just the SetLoadingEnabled(PR_FALSE) call. the rest is just cleanup. (and the Makefile change is needed, since nsIImageLoadingContent inherits from imgIDecoderObserver, and that file needs gfx headers too...)
Status: NEW → ASSIGNED
> bz/jst, is that correct? It is, yes. I'll try to look at the patch in the next few days, but I have a really slow connection for this next week, so dealing with bugs is .... fun. ;)
*** Bug 275680 has been marked as a duplicate of this bug. ***
Comment on attachment 169138 [details] [diff] [review] possible patch r=bzbarsky
Attachment #169138 - Flags: review?(bzbarsky) → review+
Comment on attachment 169138 [details] [diff] [review] possible patch sr=jst
Attachment #169138 - Flags: superreview?(jst) → superreview+
Comment on attachment 169138 [details] [diff] [review] possible patch this should be a pretty low risk patch... just disables loading images in the copy of the DOM node that the save code makes
Attachment #169138 - Flags: approval1.8a6?
Comment on attachment 169138 [details] [diff] [review] possible patch a=asa for checkin to 1.8a6
Attachment #169138 - Flags: approval1.8a6? → approval1.8a6+
Checking in embedding/components/webbrowserpersist/src/Makefile.in; /cvsroot/mozilla/embedding/components/webbrowserpersist/src/Makefile.in,v <-- Makefile.in new revision: 1.11; previous revision: 1.10 done Checking in embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp; /cvsroot/mozilla/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp,v <-- nsWebBrowserPersist.cpp new revision: 1.102; previous revision: 1.101 done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 279353 has been marked as a duplicate of this bug. ***
*** Bug 219679 has been marked as a duplicate of this bug. ***
*** Bug 299446 has been marked as a duplicate of this bug. ***
Still seeing the problem in many errors caused from Firefox on my website (error_log). Latest version seeing the problem: 1.0.7. Therefore asking for blocking 1.0.8. pi
Flags: blocking-aviary1.0.8?
1.0.x is security-only, I find it extremely unlikely that people will approve this patch for those releases.
I can confirm that this issue is still persistent in Firefox 1.0.7 and also in Mozilla 1.7.12. Windows and linux-versions alike.
If this bug cannot be marked as blocking (though I agree with Boris that this would be appropriate) it should at least be reopened. "Status: Resolved" and "Resolution: Fixed" are both obviously incorrect.
they are obviously correct, just get firefox 1.5rc1 or seamonkey 1.0alpha to observe that. the resolution refers to trunk.
To quote the announcement of stopping to work for Mozilla 1.8: "At that time we also stated our intention to maintain a long-lived, stable 1.7.x version of Seamonkey." - Do not know about release policies for Firefox. Stable includes bugfixes and not only security-fixes in my opinion. And this is a _bug_ of Mozilla 1.7.12 and should therefore be fixed in Mozilla 1.7.13. It is not a new feature (which of course wouldn't be implemented in Mozilla anymore - do not know about Firefox 1.0.x either). Furthermore it is not a problem of my own and therefore your proposal to download a new browser doesn't help me (or 3.14@piology.org who also posted about 404-messages in his weblogs) at all. It is a problem of people using my website (and other websites). We see a hell of a lot 404er messages in our logfiles because of this bug. And that is annoying.
I'm sure this was meant to be nominated for 1.7.13 as well (comment 27)
Flags: blocking1.7.13?
Not in the scope of a security release
Flags: blocking1.7.13?
Flags: blocking1.7.13-
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8-
This is only partially fixed in Firefox 1.5 & 1.5.0.1. For example go to http://www.jr.com/ and select a product page, eg http://www.jr.com/JRProductPage.process?Product=4050716 then save it, causing: GET http://www.jr.com/JRProductPage.process_files/btn_go.gif HTTP/1.1 GET http://www.jr.com/JRProductPage.process_files/btn_add_to_cart.gif HTTP/1.1 GET http://www.jr.com/JRProductPage.process_files/btn_add_selected_items.gif HTTP/1.1 Please could someone reopen it.
oh, dammit. I forgot about <input type="image">.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I guess trunk needs this for <object> too, but I'd like to do this in another bug, as that's more complicated...
Attachment #211144 - Flags: superreview?(bzbarsky)
Attachment #211144 - Flags: review?(bzbarsky)
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.8alpha6 → mozilla1.8.1
Comment on attachment 211144 [details] [diff] [review] also fix input type="image" So.... r+sr=bzbarsky, but I just realized that this whole approach doesn't really do the right thing when PERSIST_FLAGS_FIXUP_ORIGINAL_DOM is set, does it? Perhaps it would make more sense to create a data-only document when that flag is not set and instead of CloneNode call ImportNode on the data doc? Then we'd get blocking of all loads, including object etc, for free and not have to play this whack-a-mole as we introduce new types (for example, <svg:image> has issues as things stand).
Attachment #211144 - Flags: superreview?(bzbarsky)
Attachment #211144 - Flags: superreview+
Attachment #211144 - Flags: review?(bzbarsky)
Attachment #211144 - Flags: review+
See bug 325822; might want to file a followup dependent on that?
SVG images seems to do the same as HTML images... filed bug 327822 Checking in embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp; /cvsroot/mozilla/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp,v <-- nsWebBrowserPersist.cpp new revision: 1.116; previous revision: 1.115 done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
Comment on attachment 211144 [details] [diff] [review] also fix input type="image" we should take this on the branch too.
Attachment #211144 - Flags: approval-branch-1.8.1?(bzbarsky)
Attachment #211144 - Flags: approval-branch-1.8.1?(bzbarsky) → approval-branch-1.8.1+
fixed on MOZILLA_1_8_BRANCH Checking in embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp; /cvsroot/mozilla/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp,v <-- nsWebBrowserPersist.cpp new revision: 1.109.8.3; previous revision: 1.109.8.2 done
Keywords: fixed1.8.1
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: