[Webkit-unassigned] [Bug 14298] New: Wrong base URL used for pages loaded by custom protocol handler

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14298

           Summary: Wrong base URL used for pages loaded by custom protocol
                    handler
           Product: WebKit
           Version: 419.x
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: UNCONFIRMED
          Severity: Blocker
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: rush at manbert.com


Summary: 
In the current shipping version of the WebKit framework, if I load the HTML for
a web page using a custom protocol and set my desired base URL in the
NSURLResponse by calling:
        [NSURLResponse initWithURL:  MIMEType: expectedContentLength:
textEncodingName:
then that base URL is used to resolve any relative resource references in the
loaded HTML. For instance, if I set the base URL to
"file://localhost//Users/rmanbert/something/" and my HTML contains this
element:
        <script type="text/javascript" src="test.js"></script>
then the full URL that is used will be
"file://localhost//Users/rmanbert/something/test.js"

In the nightly build of WebKit, this behavior is different. It appears that the
base URL I set in my NSURLResponse is being ignored, and the base URL from the
NSURLRequest is being used instead. Given the same example above, if the
NSURLRequest that I retrieve in my startLoading method of my protocol handler
has a URL of the form "special://loadString/", but I set the URL in the
NSURLResponse as I did above, then when my script element is processed, WebKit
resolves the relative reference as "special://loadString/test.js".

I rely on being able to set the base URL in my startLoading method, and this
change in behavior has broken my app. I also believe it is incorrect behavior
because people may use custom protocols to implement all sorts of different
content loading schemes. Consider a case where different "special://" URLs are
used as selectors for HTML content that is baked into the app for security
reasons. The easiest way to load a JavaScript library from within the HTML
would be to use a relative URL and manage the base URL in the startLoading
method. It would be entirely reasonable to set the base URL to reference the
application bundle resource folder, but you certainly would not want the base
URL to be something like "special:///selector1".

In my case, I have an app that must run on the Mac and on Windows. I have a
custom markup language that extends XHTML. Displaying my content relies on
transforming the XHTML source with XSLT, as well as performing other
manipulations on the DOM tree. In order to minimize browser-related problems, I
use libxml and libxslt to process my source into a HTML string, and I use a
custom protocol handler to load the HTML string into my WebKit view. I use
JavaScript libraries that are loaded by the HTML, so I need to control the base
URL.

Steps to Reproduce: 
I have attached (Well, I hope I will be able to attach) a sample project in the
file "WebKitBadBaseUrl.zip" that demonstrates the problem. It is based on
Apple's Special Picture Protocol sample project, and I have modified it to
simulate the way my application loads its web pages. The basic method for
loading a page with a URL of the form "special:///file.html" is to read the
contents of the file into a string. This simulates my rendering process. I then
put the HTML string, plus a string that represents the path portion of the 
desired base URL into a NSDictionary, which I attach to a new NSURLRequest.
This request carries the URL "something://loadString/", which is exactly what
my real application does. We then rely on the startLoading method in
SpecialProtocol.m to extract the HTML string and the base URL path. The string
becomes the returned data and the path gets incorporated into a file: URL to
make the desired base URL.

The HTML contains a <script> tag that references a file that is stored in the
application bundle resources folder. If the base URL works as expected, the web
page is displayed. It contains a single line of text. If the base URL does not
get set as desired, then this is detected in:
-(NSURLRequest *)webView:(WebView *)sender resource: willSendRequest:
redirectResponse: fromDataSource:
in MyController.m. It displays an alert and exits the program with an error.

To demonstrate proper and improper behavior:
1) Build the project for Debug under OS X 10.4.x
2) Run the program and note that the web page is displayed. It displays the
text "Content from test.html". This is the proper behavior because the relative
reference of "test.js" in the HTML was resolved to the proper file URL for the
test.js file stored in the application bundle resource folder.
3) Now we need to make the application run with the nightly build WebKit. Here
is one method:
  a) Go to the SpecialPictureProtocol project window and open the "Executables"
section
  b) Right click on SpecialPictureProtocol and select "Get Info" from the drop
down menu
  c) Click on the "Arguments" tab
  d) Add two environment variables in the lower panel. Their names and values
are as follow:
      WEBKIT_UNSET_DYLD_FRAMEWORK_PATH   YES
      DYLD_FRAMEWORK_PATH    $(PROJECT_DIR)/WebKit.app/Contents/Resources

      See the file CustomExecutableArgumentsSettings.tiff in the project
directory for a screenshot.
4) Once the environment variables have been set, run the application again.
This time you should see an error alert saying that there is a base URL error.


Expected Results: 
I expected the base URL that I set in my startLoading method to be used when
resolving relative URLs within the loaded HTML.

Actual Results: 
The "dummy" special protocol URL was used as the base URL. This is the URL that
was in the NSURLRequest that caused us to invoke startLoading.

Regression: 
This works as expected in WebKit frameworks released with 10.4.x. It does not
work as expected in the nightly build.

Notes: 
The demonstration XCode project is in the attached file "WebKitBadBaseUrl.zip".

I was advised on the webkit-dev mailing list to file bugs with Apple and here,
so that's what I'm doing.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.