Yeah, I definitely agree that either undef or sub { 1 } is confusing. I
thought about static yes/no being booleans, but then I thought undef didn't
make sense because then you would never serve a compressed asset, so why
use the role?
I was hoping undef would make sense from the perspective that there is no
sub, so I cannot check and assume true, but I agree that that is
counterintuitive to undef normally meaning false.
For any non-sub value meaning false and requiring sub { 1 } for always
true, I'm not sure that that's any clearer, and it does require the
inefficiency.
Maybe the correct answer is letting non-sub values evaluate to their
natural boolean value, and maybe warning if a false value is set that the
role will never serve a compressed asset and is useless?
On Thu, Apr 11, 2019, 10:20 Joel Berger <[email protected]> wrote:
> I'm no expert in this stuff so I won't comment too much on the mechanism.
> One comment I do have is that "should_serve_asset" being either undef or
> sub { 1 } both mean yes is really confusing. I'd suggest that you make the
> static yes/no be booleans and only consider the subref if passed a subref.
> (Aside: you could even take it further I suppose and have any non-sub value
> be false and require sub { 1 } to mean always true, but that does introduce
> some inefficiency.)
>
> Cheers,
> Joel
>
> On Thursday, April 11, 2019 at 12:05:50 AM UTC-5, Adam Hopkins wrote:
>>
>> I've come up with an attempted solution. It's not finished yet (no tests
>> and I haven't published to CPAN), because I was hoping to get some feedback
>> if anyone has time before I move further in case it's not a great solution
>> :)
>>
>> I created a role that uses the before method modifiers on serve_asset
>> <https://metacpan.org/pod/Mojolicious::Static#serve_asset> and is_fresh
>> <https://metacpan.org/pod/Mojolicious::Static#is_fresh>.
>>
>> In the serve_asset before, I check if serving a compressed asset is
>> appropriate (the asset is a Mojo::Asset::File, the compressed asset exists
>> for the file, the client accepts that type of encoding), and then serve if
>> while adding the necessary headers (content_encoding, etc). If none of
>> those conditions are met, the uncompressed asset will be served.
>>
>> The is_fresh before method is used only if a compressed asset exists to
>> set the last modified time of the compressed asset to the last modified
>> time of the uncompressed asset, and also to modify the etag to contain the
>> encoding at the end.
>>
>> I would really appreciate any feedback or recommendations :) Here's a
>> link to the github repo, which has a README with documentation:
>>
>> https://github.com/srchulo/Mojolicious-Static-Role-Compressed
>>
>> On Monday, April 1, 2019 at 11:38:55 PM UTC-5, Adam Hopkins wrote:
>>>
>>> Hi all,
>>>
>>> I wanted to get some feedback on how to approach serving compressed
>>> static assets. I have my static assets along with pre-compressed versions
>>> of the assets via gzip and brotli. I’d like to serve static assets first by
>>> the brotli compressed asset if it exists, then gzip if it exists
>>> (preferrably the smallest first, but that should be the brotli asset if it
>>> exists), then the regular asset if there is neither.
>>>
>>> I had mentioned this in the #mojo IRC channel, and kraih and batman had
>>> recommended maybe this would make sense as a part of
>>> Mojolicious::Plugin::AssetPack
>>> <https://metacpan.org/pod/Mojolicious::Plugin::AssetPack>. However, now
>>> I already have the assets compressed, so I’m not sure that this would make
>>> sense.
>>>
>>> A suggestion was made that a before_dispatch
>>> <https://mojolicious.org/perldoc/Mojolicious#before_dispatch> hook
>>> could maybe look at Accept-Encoding and modify the request if gzip or br
>>> was accepted and the file existed. I have a few concerns with this after
>>> thinking about it. One is that this won’t work for static files that are
>>> served via reply->static
>>> <https://metacpan.org/pod/Mojolicious::Plugin::DefaultHelpers#reply-%3Estatic>,
>>> or serve in Mojolicious::Static
>>> <https://metacpan.org/pod/Mojolicious::Static#serve>. Another concern
>>> is that the Last-Modified time for asset.css.gzip isn’t guaranteed to be
>>> the same as asset.css, and I feel like asset.css’s Last-Modified time is
>>> what should be used. Another is that ETags are suppose to be content coding
>>> aware:
>>>
>>> https://tools.ietf.org/html/rfc7232#section-2.3.3
>>>
>>> And since Mojolicous::Static
>>> <https://metacpan.org/pod/Mojolicious::Static> calls md5_sum
>>> <https://metacpan.org/pod/Mojo::Util#md5_sum> on the files
>>> Last-Modified time, it’s not guaranteed that the different content-codings
>>> will have different ETags.
>>>
>>> After thinking about all of this, it seems like what would need to be
>>> done is create a Mojolicious::Static
>>> <https://metacpan.org/pod/Mojolicious::Static> class or a subclass. I
>>> believe maybe just serve in Mojolicious::Static
>>> <https://metacpan.org/pod/Mojolicious::Static#serve> would need to be
>>> overridden. However, I definitely prefer to avoid this approach as changes
>>> in Mojolicious::Static <https://metacpan.org/pod/Mojolicious::Static>
>>> or what methods Mojolicious <https://metacpan.org/pod/Mojolicious>
>>> expects the object in static
>>> <https://metacpan.org/pod/Mojolicious#static> to handle could cause it
>>> to break. Also, there's a lot of HTTP/RFC login in serve, and I'd prefer
>>> not to mess with that.
>>>
>>> Is there a good way to solve this with a plugin? Or am I correct in
>>> assuming that this would need to happen at some level in the object in
>>> static <https://metacpan.org/pod/Mojolicious#static>?
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
