Done: https://issues.apache.org/jira/browse/WICKET-5873
Regards
Nick
On Mon, Apr 6, 2015 at 12:22 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:
> Afaik it didn't break anything in 7.x so I think it is safe to be back
> ported.
> Please file a ticket.
> On Apr 6, 2015 7:20 PM, "Nick Pratt" <nbpr...@gmail.com> wrote:
>
> > Any chance it can be back ported into 6.20 ?
> >
> >
> >
> > On Mon, Apr 6, 2015 at 12:17 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > We've figured out that some time ago and removed it for Wicket 7.x.
> > > On Apr 6, 2015 7:00 PM, "Nick Pratt" <nbpr...@gmail.com> wrote:
> > >
> > > > OK, now the Wicket cause of this: Why in AbstractResource do we flush
> > the
> > > > response after writing the headers (which is invoked from
> > > > setResponseHeaders() )?
> > > > /**
> > > >
> > > > * Flushes the response after setting the headers.
> > > > * This is necessary for Firefox if this resource is an image,
> > > > * otherwise it messes up other images on page.
> > > > *
> > > > * @param response
> > > > * the current web response
> > > > */
> > > > protected void flushResponseAfterHeaders(final WebResponse response)
> > > > {
> > > > response.flush();
> > > > }
> > > >
> > > >
> > > > If this issue is solely for images in some (older) version of
> Firefox,
> > > > is there any reason we have to do this for .css and .js files being
> > > > served?
> > > >
> > > >
> > > > Nick
> > > >
> > > >
> > > > On Mon, Apr 6, 2015 at 11:32 AM, Nick Pratt <nbpr...@gmail.com>
> wrote:
> > > >
> > > > > I had a feeling I did, but the problem still remains. Anyway, the
> > > > > resources served by Wicket are served on a response that is
> committed
> > > > > (likely due to a flush() invocation). The Jetty
> > > > CompressedResponseWrapper
> > > > > does not compress committed responses:
> > > > >
> > > > > public ServletOutputStream getOutputStream() throws IOException
> > > > >
> > > > > {
> > > > > if (_compressedStream==null)
> > > > > {
> > > > > if (getResponse().isCommitted() || _noCompression)
> > > > > return getResponse().getOutputStream();
> > > > >
> > > > >
> > > >
> > >
> >
> _compressedStream=newCompressedStream(_request,(HttpServletResponse)getResponse());
> > > > > }
> > > > > else if (_writer!=null)
> > > > > throw new IllegalStateException("getWriter() called");
> > > > >
> > > > > return _compressedStream;
> > > > > }
> > > > >
> > > > >
> > > > > Is there anyway to not have Wicket commit the response when serving
> > > > resources (although Im unsure why the response being committed is an
> > > issue
> > > > for the Gzip Filter)
> > > > >
> > > > >
> > > > > On Mon, Apr 6, 2015 at 1:23 AM, Martin Grigorov <
> > mgrigo...@apache.org>
> > > > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >>
> > > > >> You have asked the same question 2 years ago :-)
> > > > >>
> > > > >>
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/wicket-users/201211.mbox/%3CCALpvOjtq4=hWkLO=ShUBfG7cZFS+yB-XmWgU+worrgYcTk=+3...@mail.gmail.com%3E
> > > > >>
> > > > >> How does the GZipFilter configuration looks like in your web.xml ?
> > > > >> Put a debugger in it and see what happens when a Wicket static
> > > resource
> > > > is
> > > > >> requested.
> > > > >>
> > > > >> Martin Grigorov
> > > > >> Freelancer, available for hire!
> > > > >> Wicket Training and Consulting
> > > > >> https://twitter.com/mtgrigorov
> > > > >>
> > > > >> On Sun, Apr 5, 2015 at 8:52 PM, Nick Pratt <nbpr...@gmail.com>
> > wrote:
> > > > >>
> > > > >> > We've checked all the headers and everything looks fine. The
> only
> > > > >> > difference between whether or not Jetty 9.x gzips the files is
> > > whether
> > > > >> > Wicket serves the resources. Wicket generated HTML markup is
> > > gzipped,
> > > > >> as
> > > > >> > are all static resources served by Jetty's DefaultServlet. Any
> > .js
> > > or
> > > > >> .css
> > > > >> > files served as PackageResources are not served gzipped to the
> > > client.
> > > > >> >
> > > > >> > N
> > > > >> >
> > > > >> > On Sun, Apr 5, 2015 at 3:33 AM, Christoph Läubrich <
> > > > >> lae...@googlemail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Have you checked that the correct content-type is specified?
> > > > >> > > We use Jetty8 in a project with Wicket6 and serving package
> > > resource
> > > > >> > files
> > > > >> > > gzipped works without a problem.
> > > > >> > > What kind of Packe-Resource-Files do you see not beeing
> gziped?
> > > Can
> > > > >> you
> > > > >> > > share Request/Response headers?
> > > > >> > >
> > > > >> > > Am 03.04.2015 23:56, schrieb Nick Pratt:
> > > > >> > >
> > > > >> > >> Can resources served from Wicket be gzipped by Jetty's
> > > GzipFilter?
> > > > >> > >>
> > > > >> > >> We've added the GzipFilter to a simple Quickstart (in front
> of
> > > the
> > > > >> > >> WicketFilter). We can request and receive gzipped files
> (such
> > as
> > > > >> static
> > > > >> > >> .css and .js files) served from Jetty's DefaultServlet, and
> we
> > > see
> > > > >> that
> > > > >> > >> .html files served through Wicket (such as Home.html) are
> being
> > > > >> > compressed
> > > > >> > >> by Jetty. However, all JS/CSS resources served via
> > > > PackageResources
> > > > >> are
> > > > >> > >> not being sent gzipped and we're wondering why this might be
> > the
> > > > >> case.
> > > > >> > >> We've confirmed the various caveats in the GzipFilter
> > > documentation
> > > > >> for
> > > > >> > >> Jetty 9.2.x are being fulfilled but dont see why package
> > > resources
> > > > >> files
> > > > >> > >> are not being gzipped?
> > > > >> > >>
> > > > >> > >> Regards
> > > > >> > >>
> > > > >> > >> Nick
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > ---------------------------------------------------------------------
> > > > >> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > > >> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
