* [edbrowse-dev] resolveURL question
@ 2019-07-01 3:56 Kevin Carhart
2019-07-01 4:43 ` Karl Dahlke
0 siblings, 1 reply; 2+ messages in thread
From: Kevin Carhart @ 2019-07-01 3:56 UTC (permalink / raw)
To: edbrowse-dev
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?
^ permalink raw reply [flat|nested] 2+ messages in thread
* [edbrowse-dev] resolveURL question
2019-07-01 3:56 [edbrowse-dev] resolveURL question Kevin Carhart
@ 2019-07-01 4:43 ` Karl Dahlke
0 siblings, 0 replies; 2+ messages in thread
From: Karl Dahlke @ 2019-07-01 4:43 UTC (permalink / raw)
To: edbrowse-dev
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-07-01 4:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-01 3:56 [edbrowse-dev] resolveURL question Kevin Carhart
2019-07-01 4:43 ` Karl Dahlke
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).