fix: UnboundLocalError: cannot access local variable netloc where it …

[bukzor]

…is not associated with a value

[sirosen]

Thanks for this!

The fix looks good, but could you share how you encountered this? I can't think of a way to test this behavior. It seems like you would need some kind of crafted URI which I'm not able to imagine at present.

[sirosen]

I've gone ahead with a merge, since I'd rather include this fix than leave it unpatched, but I still don't see how this scenario is reachable. Without that, I can't add a regression test and this could break in the future without warning.

If you're able to share the scenario which triggered this, that would be a tremendous help!
Either way, thanks for the contribution. 🙂

[bukzor]

A uri like file: x hits this path. Such a url reveals several other bugs as well though which I'm working on intermittently.

[sirosen]

I'm not sure how such a URL could get past the earlier check for if not filename.startswith("file://"): (this block of code is in the else branch).

I'm pretty sure that file: x is not a valid file URI, though it might not be all that relevant. (My understanding is that file URIs are specified as requiring absolute paths, even though many applications support the use of relative paths.)

I'll try to reproduce the behavior, but I am somewhat concerned by the fact that it still isn't clear to me how this could happen.

[bukzor]

file:x is a valid netloc-relative, relative-path uri. In the spec, it's the `path-rootless` alternative of `path` https://datatracker.ietf.org/doc/html/rfc3986#section-3.3 I've been working toward getting check-jsonschema to accept such uris, so I may have had a "fix" in place to no longer assume file uris are relative, although my intent and my recollection is that this PR contains all changes I had at the time. Your filename.startswith("file://") check is (technically) bugged. Its intent is to check for `file` scheme, but it's making invalid assumptions about `file` uris by also checking for `//`. Consistently using urlsplit to introspect uris will completely avoid this kind of subtle bug.

…

On Fri, Aug 2, 2024, 5:39 PM Stephen Rosen ***@***.***> wrote: I'm not sure how such a URL could get past the earlier check for if not filename.startswith("file://"): (this block of code is in the else branch). I'm pretty sure that file: x is not a valid file URI, though it might not be all that relevant. (My understanding is that file URIs are specified as *requiring* absolute paths, even though many applications support the use of relative paths.) I'll try to reproduce the behavior, but I am somewhat concerned by the fact that it still isn't clear to me how this could happen. — Reply to this email directly, view it on GitHub <#465 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE4KSH4NHPTCWMGTHZOTRTZPQDALAVCNFSM6AAAAABLPLIBKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRWGIZDENRXGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>