Giters

mozilla / libdweb

Extension containing an experimental libdweb APIs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

support redirects in protocol handlers

Gozala opened this issue · comments

commented

This is followup on #2 where are more details & context for this, but here is a short summary:

Async redirects - Turns out we could do async redirects that should enable @lidel to redirect requests from old encoding to a new encoding. Specifically it seems that channel could invoke asyncOnChannelRedirect on corresponding nsIChannelEventSink, unfortunately I do not know how to get a reference to it but I hope to find that out soon from the necko engineer who's helping me out with this.

commented

@Gozala is this any easier to do now that we have async handler, or unrelated?

(I cannot stress enough that if we could just redirect from case-sensitive CIDv0 in ipfs:// URL to a normalized, case-insensitive one, that would be huuge UX win for our upcoming move to Base32 CIDv1)

commented

@Gozala is this any easier to do now that we have async handler, or unrelated?

Nope it's unrelated.

(I cannot stress enough that if we could just redirect from case-sensitive CIDv0 in ipfs:// URL to a normalized, case-insensitive one, that would be huuge UX win for our upcoming move to Base32 CIDv1)

Please note that even when we implement redirects, that does not necessarily going to solve that as you'd still get request.url that has host fragment in lower case and there for you won't be able to change encoding.

To address the redirection from case sensitive encoding to case insensitive encoding that would require one of the following:

  1. Capture address without it being normalized and I'm not sure if that is going to be possible with standard URL protocol.
  2. Add support for URIs which unlike URLs are case-sensitive. But that is whole another can of worms because:
    1. There origin is either full URI (which is super restrictive), or null super permissive. Adding origin support would be really difficult.
    2. Specific protocol is either handler of URLs or URIs but not both. Which is to say if we aren't able to capture address before it's normalized there will be no way to say redirect from case sensitive URI to case insensitive URL.
  3. Have something like dweb://ipfs/${case_sensitive}/ redirect to ipfs://${case_insesitive}. That's probably going to work with just redirect support but not sure if it's going to help much with a UX as people might still enter ipfs://${case_sensitive}/ and fail to reach content.