On 2021-06-23, Diana Eichert <deich...@wrench.com> wrote:
> On Mon, Jun 21, 2021 at 5:35 AM Stuart Henderson <s...@spacehopper.org> wrote:
>>
> SNIP
>>
>> The location matches this block:
>>
>> >> location "/rainloop/*" {
>> >> fastcgi param SCRIPT_FILENAME "/htdocs/rainloop/index.php"
>> >> fastcgi socket "/run/php-fpm.sock"
>> >> # directory index "index.php"
>> >> }
>>
>> so it ought to be served by rainloop's front controller in
>> /htdocs/rainloop/index.php and thus the content-type ought to be
>> dictated by rainloop..
>>
>> I am wondering about the doubled path entry /rainloop/rainloop/ and
>> whether that is involved in the problem, perhaps making it serve
>> an error page not the expected css. (Opening that url directly
>> would prove that).
>>
>> If so, perhaps httpd.conf "strip" might help (though probably the
>> bit that wants a component stripping is actually PATH_INFO and the
>> documentation doesn't talk about changing that, but it maybe the
>> doc rather than the code that is incomplete).
>
> I thought the config was a little odd, but that was the config based
> upon rainloop info.
>
> If I bypass index.php and access css file with direct URL the file is
> found, but it still has the incorrect mime type associated with it.
>
> thanks
>
> diana
>
>
How about
https://mail.shopnet.com/rainloop/v/1.16.0/static/css/app.min.css?standard
instead of
https://mail.shopnet.com/rainloop/rainloop/v/1.16.0/static/css/app.min.css?standard
?
Wondering if they both get served but only one with the correct mime type.
Looking at nginx config examples for rainloop, most are using try_files to
serve the static resources directly from the webserver and only falling
back to the front-controller if they don't exist .. so you could have
a location block for .php files, a location block for static existent
files, and then a "location not found" block with the
fastcgi param SCRIPT_FILENAME "/htdocs/rainloop/index.php".
