Fix import chaining for custom header support #618
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes dhall-lang/dhall-json#60
In the above issue, a remote import specified custom headers using a
relative path:
But import chaining was not working correctly for the
using
clause of theimport, meaning that before this change the
./headers
import was notanchored to the parent import.
Using the
</>
judgment from the standard, the previous behavior was:... when the behavior should have been:
Note that custom header support has not yet been fully standardized, but the
latter version is what the correct behavior should be once it is standardized.
The reason the former version is problematic is because it does not behave
correctly in the presence of header forwarding. If
http://example1.com/bar
imports any remote expressions of its own, it will use the relative import
./baz
to customize the headers for downstream imports from the same domain.However, because this relative import is not anchored to the parent import, it
will change for each downstream import.
For example, suppose that the contents of
http://example1.com/bar using ./baz
are:Import chaining that after its parent import would give:
... which introduces an inadvertent import cycle because now
./baz
willresolve to
http://example1.com/baz
instead ofhttp://example0.com/baz
. Animport cycle similar to this one caused the bug described by the linked issue.
This change fixes import chaining to correctly anchor custom header imports to
the parent import and this fix resolves the above issue.
This also includes a small change to fix canonicalization to also canonicalize
the custom header import, although this is unrelated to the above bug.