Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support redirects in protocol handlers #34

Closed
Gozala opened this issue Jul 23, 2018 · 3 comments
Closed

support redirects in protocol handlers #34

Gozala opened this issue Jul 23, 2018 · 3 comments
Labels
Protocol Protocol API related issues

Comments

@Gozala
Copy link
Contributor

Gozala commented Jul 23, 2018

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.

@Gozala Gozala added the Protocol Protocol API related issues label Jul 23, 2018
@lidel
Copy link
Contributor

lidel commented Aug 16, 2018

@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)

@Gozala
Copy link
Contributor Author

Gozala commented Aug 18, 2018

@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.

@Gozala
Copy link
Contributor Author

Gozala commented Aug 7, 2019

Migrate to https://bugzilla.mozilla.org/show_bug.cgi?id=1572206

@Gozala Gozala closed this as completed Aug 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Protocol Protocol API related issues
Projects
None yet
Development

No branches or pull requests

2 participants