search

sleemanj / xinha

WYSIWYG HTML Editor Component (turns <textarea> into HTML editors)
http://trac.xinha.org/
Other
13 stars 2 forks source link

expandRelativeUrls behaviour with intentionally (document) relative URLs (Trac #1727) #1727

Open sleemanj opened 6 years ago

sleemanj commented 6 years ago

1484 and changeset:1396 introduced a rewrite of the relative url expansion.

expandRelativeUrls which is done as part of fixRelativeLinks was intended originally as a fix for when dragging around images and links firefox would change urls to be relative to the file containing the Xinha editor, rather than the document being edited (baseHref).

It originally only did anything with URLs that contained ../ and thenceforth expected that they must be these badly-relative ones and "fixed" them.

The process implemented in changeset:1396 is a little broader and also expanded relative URLs which do not contain ../

This creates a problem when you legitimately want a relative URL in your HTML, for example you feed in HTML like

    <a href="../index.html">Parent Directory</a>

then expandRealtiveURls (in either incarnation) would mess with that URL in a way you didn't want probably.

As a stop-gap fix changeset:1433 will prevent by default the expansion of URLs which start with something that's not parental or self-referential. That is to say, "foo/bar.html" will not be touched, but "../foo/bar.html" will be touched, absolute urls including such a parental or self referential component, like "/foo/../bar.html, will also not be touched.

A better fix long-term would be I think to expand relative URLs incoming to the document url (baseHref) (in inwardHTML) and expand relative URs outgoing (in outwardHTML) to the file including Xinha, and also have an option to "contract" (opposite of expand) semi-absolute urls to be relative to the document url. Effectively, we need two different operations for fixRelativeLinks one for incoming and one for outgoing.

Reported by @sleemanj, migrated from http://trac.xinha.org/ticket/1727

sleemanj commented 6 years ago

@sleemanj changed description from:

1484 and changeset:1396 introduced a rewrite of the relative url expansion.

expandRelativeUrls which is done as part of fixRelativeLinks was intended originally as a fix for when dragging around images and links firefox would change urls to be relative to the file containing the Xinha editor, rather than the document being edited (baseHref).

It originally only did anything with URLs that contained ../ and thenceforth expected that they must be these badly-relative ones and "fixed" them.

The process implemented in changeset:1396 is a little broader and also expanded relative URLs which do not contain ../

This creates a problem when you legitimately want a relative URL in your HTML, for example you feed in HTML like

    <a href="../index.html">Parent Directory</a>

then expandRealtiveURls (in either incarnation) would mess with that URL in a way you didn't want probably.

As a stop-gap fix changeset to be committed next will prevent by default the expansion of URLs which start with something that's not parental or self-referential. That is to say, "foo/bar.html" will not be touched, but "../foo/bar.html" will be touched, absolute urls including such a parental or self referential component, like "/foo/../bar.html, will also not be touched.

A better fix long-term would be I think to expand relative URLs incoming to the document url (baseHref) (in inwardHTML) and expand relative URs outgoing (in outwardHTML) to the file including Xinha, and also have an option to "contract" (opposite of expand) semi-absolute urls to be relative to the document url. Effectively, we need two different operations for fixRelativeLinks one for incoming and one for outgoing.

to:

1484 and changeset:1396 introduced a rewrite of the relative url expansion.

expandRelativeUrls which is done as part of fixRelativeLinks was intended originally as a fix for when dragging around images and links firefox would change urls to be relative to the file containing the Xinha editor, rather than the document being edited (baseHref).

It originally only did anything with URLs that contained ../ and thenceforth expected that they must be these badly-relative ones and "fixed" them.

The process implemented in changeset:1396 is a little broader and also expanded relative URLs which do not contain ../

This creates a problem when you legitimately want a relative URL in your HTML, for example you feed in HTML like

    <a href="../index.html">Parent Directory</a>

then expandRealtiveURls (in either incarnation) would mess with that URL in a way you didn't want probably.

As a stop-gap fix changeset:1433 next will prevent by default the expansion of URLs which start with something that's not parental or self-referential. That is to say, "foo/bar.html" will not be touched, but "../foo/bar.html" will be touched, absolute urls including such a parental or self referential component, like "/foo/../bar.html, will also not be touched.

A better fix long-term would be I think to expand relative URLs incoming to the document url (baseHref) (in inwardHTML) and expand relative URs outgoing (in outwardHTML) to the file including Xinha, and also have an option to "contract" (opposite of expand) semi-absolute urls to be relative to the document url. Effectively, we need two different operations for fixRelativeLinks one for incoming and one for outgoing.

sleemanj commented 6 years ago

@sleemanj changed description from:

1484 and changeset:1396 introduced a rewrite of the relative url expansion.

expandRelativeUrls which is done as part of fixRelativeLinks was intended originally as a fix for when dragging around images and links firefox would change urls to be relative to the file containing the Xinha editor, rather than the document being edited (baseHref).

It originally only did anything with URLs that contained ../ and thenceforth expected that they must be these badly-relative ones and "fixed" them.

The process implemented in changeset:1396 is a little broader and also expanded relative URLs which do not contain ../

This creates a problem when you legitimately want a relative URL in your HTML, for example you feed in HTML like

    <a href="../index.html">Parent Directory</a>

then expandRealtiveURls (in either incarnation) would mess with that URL in a way you didn't want probably.

As a stop-gap fix changeset:1433 next will prevent by default the expansion of URLs which start with something that's not parental or self-referential. That is to say, "foo/bar.html" will not be touched, but "../foo/bar.html" will be touched, absolute urls including such a parental or self referential component, like "/foo/../bar.html, will also not be touched.

A better fix long-term would be I think to expand relative URLs incoming to the document url (baseHref) (in inwardHTML) and expand relative URs outgoing (in outwardHTML) to the file including Xinha, and also have an option to "contract" (opposite of expand) semi-absolute urls to be relative to the document url. Effectively, we need two different operations for fixRelativeLinks one for incoming and one for outgoing.

to:

1484 and changeset:1396 introduced a rewrite of the relative url expansion.

expandRelativeUrls which is done as part of fixRelativeLinks was intended originally as a fix for when dragging around images and links firefox would change urls to be relative to the file containing the Xinha editor, rather than the document being edited (baseHref).

It originally only did anything with URLs that contained ../ and thenceforth expected that they must be these badly-relative ones and "fixed" them.

The process implemented in changeset:1396 is a little broader and also expanded relative URLs which do not contain ../

This creates a problem when you legitimately want a relative URL in your HTML, for example you feed in HTML like

    <a href="../index.html">Parent Directory</a>

then expandRealtiveURls (in either incarnation) would mess with that URL in a way you didn't want probably.

As a stop-gap fix changeset:1433 will prevent by default the expansion of URLs which start with something that's not parental or self-referential. That is to say, "foo/bar.html" will not be touched, but "../foo/bar.html" will be touched, absolute urls including such a parental or self referential component, like "/foo/../bar.html, will also not be touched.

A better fix long-term would be I think to expand relative URLs incoming to the document url (baseHref) (in inwardHTML) and expand relative URs outgoing (in outwardHTML) to the file including Xinha, and also have an option to "contract" (opposite of expand) semi-absolute urls to be relative to the document url. Effectively, we need two different operations for fixRelativeLinks one for incoming and one for outgoing.