I don't see any particular reason to block 3.1 on this, given that it works for the standard case. I don't see why we wouldn't take a patch though.
(In reply to comment #10)
> (In reply to comment #9)
> > I wonder if we really mind in the end. In which scenario would be blacklist an
> > extension for just the currently selected locale?
> >
>
> I agree that its not obvious as of why to pass a %LOCALE% to the blocklist
> server at all ...
>
> If there is no use-case for that we can just drop that component from the
> blocklist URL completely. Not sure how many backends/services rely on that
> component for parsing though.
> > Maybe just making sure that the actual char prefs are properly escaped so that
> > "/" chars don't make it through would be already good enough.
>
> Agreed, properly escaping the components would make this more fail-safe ... not
> sure if its really worth the effort though. Thoughts?
I don't see any particular reason to block 3.1 on this, given that it works for the standard case. I don't see why we wouldn't take a patch though.
(In reply to comment #10)
> (In reply to comment #9)
> > I wonder if we really mind in the end. In which scenario would be blacklist an
> > extension for just the currently selected locale?
> >
>
> I agree that its not obvious as of why to pass a %LOCALE% to the blocklist
> server at all ...
>
> If there is no use-case for that we can just drop that component from the
> blocklist URL completely. Not sure how many backends/services rely on that
> component for parsing though.
bug 430120
> > Maybe just making sure that the actual char prefs are properly escaped so that
> > "/" chars don't make it through would be already good enough.
>
> Agreed, properly escaping the components would make this more fail-safe ... not
> sure if its really worth the effort though. Thoughts?
bug 468527