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

Tue Jan 8 13:14:45 PST 2008

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

------- Comment #6 from rush at manbert.com  2008-01-08 13:14 PDT -------
(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.

-- 
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.