[edbrowse-dev] resolveURL question

[edbrowse-dev] resolveURL question

[Kevin Carhart]

Since the change in attributes, the form submit that I was trying on 
maersk now works!  The result page in self-contained form, is here:

https://www.maersk.com/tracking/#tracking/MRKU7424405

Of course it raised another thing.  I noticed a resolution issue with the 
hash-mark-and-internal-anchor syntax.

resolveURL currently makes several resolutions of JS files that are in the 
page with relative references, like this:

resolve(https://www.maersk.com/tracking/#tracking/MRKU7424405|js/vendor/requirejs/require.js)
= https://www.maersk.com/tracking/#tracking/js/vendor/requirejs/require.js

(require, modernizr, min.js and a CSS file are all done by this logic)

Yet these paths all give 404's because the real structure is like: 
https://www.maersk.com/tracking/js/vendor/requirejs/require.js

We then get messages like "CSS suppressed because content type is html" 
and the whole thing is not going to work right.

So this is almost but not quite caught by the situation described in the 
comment at line 823 of url.c, right?

/* This is an anchor for the current document, don't resolve. */
/* I assume the base does not have a #fragment on the end; that is not 
part of the base. */
/* Thus I won't get url#foo#bar */

Do you think the assumption "I assume the base does not have a #fragment 
on the end" would also hold for the situation here where it is not at 
rel[0] but the last section of base?

[edbrowse-dev] resolveURL question

[Karl Dahlke]

resolveURL seems like such a simple routine, but it has been a nightmare for about 15 years now.
That's why I have specific debug prints for it, at level 5, probably should be at level 4.
We need to see what it is doing and when it screwes up, like here.

The section you refer to is not relevant.
rel is the variable of the relative piece, and that code is for
rel = #foo
where I'm just changing the hash.
But here we have a new path, and the base has a hash, but the hash contains a slash, which I've never seen before.
parseURL handles it properly, so let's step through and see what goes wrong.
Line 885 is telling us where the problem is.
Fortunately the fix is literally a single character.

Karl Dahlke