Bertrand Delacretaz wrote > Absolute URLs are fine, it's local file references that can be > problematic, similar to your example.
I'm having trouble understanding what you're trying to state is intended to be allowed versus not at this point. I'm interpreting your separate posts over the thread into a contradiction: A) Stated that local absolute file references such as /file:/C:/test/sling/content/image1.png/ are not intended to be supported. B) Now stating that absolute URLs are intended to be supported. Is leading to a contradiction for me. This may simply be either terminology discrepancies coming into effect, or differences in perspective. the test cases within the existing codebase have only relative file references in them, there are no test cases that include absolute URLs. (For such test cases that can run across all systems, this would require some programmatic behavior to create the XMLs, so only somewhat understandable that they are missing) So maybe I'll try this from a different approach in explanation, more specifically the behavioral analysis of the before and after of SLING-2512 changes (For simplicity, assuming ideal scenario in which XML is properly formatted and referenced content files exist, etc.) example absolute URLs: * file:/C:/test/sling/content/image1.png * https://www.google.com/images/srpr/logo11w.png example relative URLs: * image1.png * images/logo.png *before SLING-2512:* a) importing with absolute URLs with the parse(URL, ContentCreator) methodology -> Works b) importing with relative URLs with the parse(URL, ContentCreator) methodology -> Works c) importing with absolute URLs with the parse(InputStream, ContentCreator) methodology -> Works d) importing with relative URLs with the parse(InputStream, ContentCreator) methodology -> MalformedURLException occurs *after SLING-2512:* a) importing with absolute URLs with parse(URL, ContentCreator) -> *Works* b) importing with relative URLs with parse(URL, ContentCreator) -> Works c) importing with absolute URLs with the parse(InputStream, ContentCreator) -> *Blocked* d) importing with relative URLs with the parse(InputStream, ContentCreator) -> *Blocked before causing MalformedURLException* I am fully behind the change in behavior for scenario "/d/". But I do not understand why scenario "/c/" degraded from being functional to being blocked altogether, especially since scenario "/a/" still functions. The current behavior appears overly inconsistent here. This particular behavioral inconsistency is what I'm seeking clarification on. - Steven -- View this message in context: http://apache-sling.73963.n3.nabble.com/Further-clarification-of-SLING-2512-tp4053816p4053904.html Sent from the Sling - Users mailing list archive at Nabble.com.
