edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [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

edbrowse-dev - development list for edbrowse

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/edbrowse-dev

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 edbrowse-dev edbrowse-dev/ http://inbox.vuxu.org/edbrowse-dev \
		edbrowse-dev@edbrowse.org
	public-inbox-index edbrowse-dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.edbrowse.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git