Summary: | Dynamically injected base tag from external script causes extra requests | ||
---|---|---|---|
Product: | WebKit | Reporter: | Scott Jehl <scott> |
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | ap, getify, japhet, john.david.dalton, koivisto, paulirish |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Mac (Intel) | ||
OS: | OS X 10.7 | ||
URL: | http://jsbin.com/umulij/8 |
Description
Scott Jehl
2011-08-18 09:41:38 PDT
I wonder if these are preloaded generated requests that are being carried on. Pretty sure they are. This is not a reasonable thing to do. -> wontfix (In reply to comment #2) > Pretty sure they are. This is not a reasonable thing to do. -> wontfix I'd really appreciate if this issue could be given a little more consideration. Injecting and/or modifying and existing base element via JavaScript is useful for a number of reasons. For one, modifying the base href is a reliable way to ensure assets that are requested via ajax-appended markup are routed through the relative URL they come from (for example, when appended HTML contains scripts, styles, images, etc). We modify the base element constantly in the jQuery Mobile framework as new pages are brought in via Ajax. I can test to see if this change has any effect there currently, as I'm not sure if it does. The case I was concerned with in particular was that the "Responsive Images" technique, which is one of only a few ways to currently route images appropriately based on screen resolution in responsive designs, no longer works because of this recent change. While this can be done other ways, the base tag approach can be the most useful depending on the site. (more here: http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/ ) That said, I think the part that needs clarification most here is why this technique works perfectly when the script is inline in the head, but not when it's referenced externally. Shouldn't these two scenarios behave the same? I've noticed that an externally referenced script is able to set a cookie that is subsequently carried by the image request, so the problem does not appear to be related to timing. In fact, looking at the profiler, the request to the non-base-href image src goes out AFTER the one that is routed properly. This seems to suggest a bug, rather than an optimized prefetch. I ask that you reconsider this bug, as it doesn't appear to match expected behavior. Thanks so much > That said, I think the part that needs clarification most here is why this technique works perfectly when the script is inline in the head, but not when it's referenced externally. Shouldn't these two scenarios behave the same?
Sounds like the difference is that the browser knows immediately during parsing the contents of inline script blocks, so it can abandon an invalidated resource preload right away if a base tag is injected. For an external script resource, the base tag injection may/will happen "later", when the script finishes loading and executes, which is likely well after the other resource loading has already started. Aborting a request/response in mid flight is probably harder to do, and also probably doesn't really save much in bandwidth on either side of the fence.
Thanks, Kyle. That's a helpful theory, but it's interesting that a cookie set within an external is successfully carried with both image requests. That seems to suggest that the script is executed before these requests go out, as I'd expect, but for some reason the base tag situation is different. Here's a demo showing image requests carrying cookies from that JS file: http://jsbin.com/ifupav/2 (src: http://jsbin.com/ifupav/2/edit ) Inserting base element effectively changes all the subsequent URLs on the page. Any script may insert one so to avoid double loads we could never load anything else as long as there is a pending script load. This would mean disabling preloading, which is out of the question. Only reasonable fix would be to ignore the base url change for elements for which we have already started loads for (HTML5 text could be interpreted like that). However that could break something and is probably not worth the effort in any case. |