Hi,
we experienced an issue with SSIs (include virtual): nginx at first decodes
the URI path and encodes it before passing the request to the upstream. If
an URI path segment contains %2F (encoded slash), the decoded slash is not
encoded again so that the request sent to the upstream differs from
Am 14.07.2014 14:54 schrieb "Maxim Dounin" :
>
> By default, nginx just sends what's already available. And for
> SSI, it uses chunked encoding.
I don't understand this. In my understanding SSI (the virtual include
directive) goes downstream (e.g. gets some data from a backend) so that the
backen
Am 13.07.2014 22:01 schrieb "Valentin V. Bartenev" :
>
> Have you tried nginx SSI module?
> http://nginx.org/en/docs/http/ngx_http_ssi_module.html
We're using the SSI module to assemble the page from various backends, but
how could SSIs help to send the head or page header early to the client?
Ch
Am 13.07.2014 18:37 schrieb "mex" :
>
> in your case i'd say the cleanest way would be a reengineering
> of your application; the other way would imply a full regex
> on every request coming back from your app-servers to filter out
> those stuff that already has been send.
> the problem: appservers
Am 13.07.2014 15:40 schrieb "mex" :
>
> sounds more like a custom solution that might be achieved using lua +
nginx;
Ok, I haven't done anything with nginx+lua so far, need to check out what
can be done with lua. Can you give some direction how lua can be helpful
here?
> from what i understand yo
Hi all,
inspired by the bigpipe pattern I'm wondering if it's possible to send the
full html head so that the browser can start downloading CSS and javascript
files.
An idea would be that the proxied backend uses a chunked encoding and sends
the html head as first chunk. The body would be sent as
