Summary: | REGRESSION: Wrong base URL used for pages loaded by custom protocol handler | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Rush Manbert <rush> | ||||
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | UNCONFIRMED --- | ||||||
Severity: | Major | CC: | abarth, aggarwalrachit33, airlinesphonenumber888, airlinesreservationsnumber, ap, azscreenrecorders1, baekchoonhwa, CassieGriffin, cogniscientofficial, dadwarner11, davidkeery, johnyaw652, ngockhanhlam87, ramtin.beheshti, sampledata17, showboxofficial01, Stengle123, thenarant, vidavera, vimalrajravi1, zwalikhan2211 | ||||
Priority: | P1 | Keywords: | InRadar, Regression | ||||
Version: | 419.x | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 37641 | ||||||
Attachments: |
|
Description
Rush Manbert
2007-06-21 16:15:46 PDT
My test case project zip file is 7.7 Mb, which is over the allowed size. It contained the copy of WebKit.app that I had tested against. I have removed WebKit.app from the project zip file and will attach it. This means that when you get to step 3 in the Steps to Reproduce section, you first need to copy a current version of WebKit.app into the project directory. The version that I used was 419.3, but you can probably use any current version. Alternatively, you could just put the project on a Leopard system and run against the WebKit framework that it contains. That shows the same error. Created attachment 15170 [details]
Test case project that does not contain WebKit.app
You must copy a current WebKit.app into the project directory before you can follow the steps to reproduce in the original bug report.
I haven't attempted to verify this, but P1/Regression handling seems appropriate anyway. If you have already filed a Radar bug, please cross-reference it with this Bugzilla one, and change "NeedsRadar" keyword to "InRadar"! The Radar bug is 5286150. I have added a comment to it that cross references to this bug. I'm not really familiar with custom protocol loaders, so it seems strange to me that such a loader can affect document url or base url somehow. Is this documented or at least hinted at anywhere? Of course, the most obvious and reliable way to change base URL when loading is to inject a BASE tag in the HTML source. (In reply to comment #5) Well, the hint is that when you initialize the NSURLResponse object that carries the metadata for the data you're loading, one of the things you specify is the URL. The documentation does not say how that URL is used. I will note, however, that the W3C HTML 4.01 specification contains a section titled "Links". It has a subsection that discusses URI resolution. I have copied it below: *************************************************** 12.4.1 Resolving relative URIs User agents must calculate the base URI for resolving relative URIs according to [RFC1808], section 3. The following describes how [RFC1808] applies specifically to HTML. User agents must calculate the base URI according to the following precedences (highest priority to lowest): 1. The base URI is set by the BASE element. 2. The base URI is given by meta data discovered during a protocol interaction, such as an HTTP header (see [RFC2616]). 3. By default, the base URI is that of the current document. Not all HTML documents have a base URI (e.g., a valid HTML document may appear in an email and may not be designated by a URI). Such HTML documents are considered erroneous if they contain relative URIs and rely on a default base URI. Additionally, the OBJECT and APPLET elements define attributes that take precedence over the value set by the BASE element. Please consult the definitions of these elements for more information about URI issues specific to them. *********************************************************** To me, item 2, which specifies the base URI as given by the metadata, and the description (in APple's documentation) of NSURLResponse as containing the metadata, implies that the URL in the NSURLResponse is indeed supposed to be used when resolving URIs in the document. But I may be wrong. When I originally wrote my custom protocol handler, I found that, after redirecting the original load request to a new custom protocol request, I was immediately seeing a load request for my CSS stylesheet, but the relative URL had been expanded using the custom protocol info, like this: myProtocol//myOp/myStylesheet.css but myStylesheet.css was actualy a file, so I needed the URL as file://localhost/myStylesheet.css and that provided the hook for me to resolve the actual full path to the stylesheet because the file: protocol handler would call my delegate method. As an experiment, since nothing said how the NSURLResponse URL was used, I initialized it to the full file: URL for the page that I had rendered and loaded with my custom protocol. The URL that I had set into the NSURLResponse was used to generate the base URL and I started to see the expected URLs for my page resources. I had opened an Apple TSI in order to get help with this, and I was working with a support guy there. I told him how I had solved the problem and he didn't tell me that it was the wrong thing to do. (He didn't tell me it was the right thing to do either. ;-) So all I can really say with authority is that it previously worked that way and now it doesn't, but I think the HTML spec implies that the previous behavior was correct. I don't understand why NSURLResponse has a URL field if it doesn't modify base URL. What good is it otherwise? Most of the examples I have seen just initialize it with the URL from the request, but they're not trying to achieve what I am. I have seen some examples where people seem to initialize it with a cache URL, but most of those posts were discussing the fact that they were having caching problems. It would be good if Apple documented how the URL in NSURLResponse gets used, but I can't find anything. I implemented my browser in Windows using the IE COM control, and because of how it works, I did implement the code to insert a <base> element (or detect that one is already there and change its href attribute). Also, because of a separate resource caching bug in WebKit, I have implemented code that resolves all of my relative references in the page at the time I render it into a HTML: string. These changes have worked around the behavior of the newest WebKit release, but it sort of scares me to do it this way. It means that I must find all of the XHTML element types that can contain URLs, examine their attributes, and do the right thing. I think I have the correct list, but I may have missed something. Being able to set the base URL by initializing the NSURLResponse pushed the identification problem off to the WebKit, which already knows how to do all of that. Me having to do it is a lot less elegant and more error prone. |