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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 25 00:11:54 PST 2019


Clark Kent <airlinesphonenumber888 at gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |airlinesphonenumber888 at gmai
                   |                            |l.com

--- Comment #13 from Clark Kent <airlinesphonenumber888 at gmail.com> ---
(In reply to Rush Manbert from comment #0)
> 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:
>       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.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190125/33ff8110/attachment-0001.html>

More information about the webkit-unassigned mailing list