Serve isso.css separately instead of inline #704
Conversation
ix5
force-pushed
the
client-css-no-inline
branch
2 times, most recently
from
7e37f99 to
a1889c0
Compare
|
Doesn't this add an extra roundtrip? |
It sure does. All these "security" features cost a lot of requests, same as for CORS preflight :( |
|
I serve JS from a CDN, not from the endpoint. It would be nice to make this configurable, but otherwise, no big trouble for me, as I also build a custom version (notably to remove languages I don't use to minimize size). |
ix5
force-pushed
the
client-css-no-inline
branch
from
a1889c0 to
5f6a160
Compare
Added |
ix5
force-pushed
the
client-css-no-inline
branch
from
5f6a160 to
ca12ce0
Compare
ix5
force-pushed
the
client-css-no-inline
branch
from
ca12ce0 to
d99b62b
Compare
Instead of embedding isso.css inside the client javascript (which required an `style-src: unsafe-inline` CSP), fetch isso.css from `api.endpoint+"/css/isso.css"`. Allow clients to override fetch location using `data-isso-css-url="https://comments.example.org/css/isso.css"` --- Note: No modification needed for packaging since isso.css is already included via MANIFEST.in. Fixes isso-comments#584
ix5
force-pushed
the
client-css-no-inline
branch
from
d99b62b to
ca1a2c7
Compare
|
Rebased, @jelmer @vincentbernat @MorrisJobke any other suggestions? |
|
Everything is good there. |
Instead of embedding isso.css inside the client javascript (which required an
style-src: unsafe-inlineCSP), fetch isso.css fromapi.endpoint+"/css/isso.css".Allow clients to override fetch location using
data-isso-css-url="https://comments.example.org/css/isso.css"Note: No modification needed for packaging since isso.css is already included via MANIFEST.in.
Fixes #584