Mailing List Archive

Hi, I am a new user of Varnish. I read the FAQ section about HTTPS. Does it mean Varnish doesn't support HTTPS requests? If so, do you have plan to support it in the future? Thanks.

L.




____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Hi,

Louis Luo skrev:
> Hi, I am a new user of Varnish. I read the FAQ section about HTTPS. Does it mean Varnish doesn't support HTTPS requests?

Varnish does not support https.

> If so, do you have plan to support it in the future? Thanks.

As far as I know there are no concrete plans to include HTTPS support. I
guess it would be a rather simple task to include HTTPS support so it
might be done on some point.

Someone just needs to want it enough to pay for it.


Per.

Hi,

Louis Luo skrev:
> Hi, I am a new user of Varnish. I read the FAQ section about HTTPS. Does it mean Varnish doesn't support HTTPS requests?

Varnish does not support https.

> If so, do you have plan to support it in the future? Thanks.

As far as I know there are no concrete plans to include HTTPS support. I
guess it would be a rather simple task to include HTTPS support so it
might be done on some point.

Someone just needs to want it enough to pay for it.


Per.

Per Andreas Buer <perbu at linpro.no> writes:
> As far as I know there are no concrete plans to include HTTPS
> support. I guess it would be a rather simple task to include HTTPS
> support so it might be done on some point.

Actually, it would be very complicated...

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Per Andreas Buer <perbu at linpro.no> writes:
> As far as I know there are no concrete plans to include HTTPS
> support. I guess it would be a rather simple task to include HTTPS
> support so it might be done on some point.

Actually, it would be very complicated...

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Dag-Erling Sm?rgrav skrev:
>
> Actually, it would be very complicated...

Oh. I guess I'm wrong, then. I though it was the simple matter of
linking in some SSL library and let it do its magic. Whats the complication?


Per.

Dag-Erling Sm?rgrav skrev:
>
> Actually, it would be very complicated...

Oh. I guess I'm wrong, then. I though it was the simple matter of
linking in some SSL library and let it do its magic. Whats the complication?


Per.

You could always setup an SSL frontend that will then communicate with
Varnish on the backend.

Check out Pound:

http://www.apsis.ch/pound/

On 3/3/08, Per Andreas Buer <perbu at linpro.no> wrote:
> Dag-Erling Sm?rgrav skrev:
> >
> > Actually, it would be very complicated...
>
> Oh. I guess I'm wrong, then. I though it was the simple matter of
> linking in some SSL library and let it do its magic. Whats the complication?
>
>
> Per.
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-dev
>

You could always setup an SSL frontend that will then communicate with
Varnish on the backend.

Check out Pound:

http://www.apsis.ch/pound/

On 3/3/08, Per Andreas Buer <perbu at linpro.no> wrote:
> Dag-Erling Sm?rgrav skrev:
> >
> > Actually, it would be very complicated...
>
> Oh. I guess I'm wrong, then. I though it was the simple matter of
> linking in some SSL library and let it do its magic. Whats the complication?
>
>
> Per.
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-dev
>

I am trying to use Nginx's SSL feature to offload SSL connections. But wouldn't this impose extra overhead?BTW, some ticket mentioned that compression would be added to 2.0. How is it now? I need this feature badly. Do you guys have some early work that I can try?Thanks,L.> You could always setup an SSL frontend that will then communicate with> Varnish on the backend.>> Check out Pound:>> http://www.apsis.ch/pound/>>On 3/3/08, Per Andreas Buer <perbu at linpro.no> wrote:> > Dag-Erling Sm?rgrav skrev:
> > >
> > > Actually, it would be very complicated...
> >
> > Oh. I guess I'm wrong, then. I though it was the simple matter of
> > linking in some SSL library and let it do its magic. Whats the complication?
> >
> >
> > Per.
> > _______________________________________________
> > varnish-dev mailing list
> > varnish-dev at projects.linpro.no> > http://projects.linpro.no/mailman/listinfo/varnish-dev> >







____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

I am trying to use Nginx's SSL feature to offload SSL connections. But wouldn't this impose extra overhead?BTW, some ticket mentioned that compression would be added to 2.0. How is it now? I need this feature badly. Do you guys have some early work that I can try?Thanks,L.> You could always setup an SSL frontend that will then communicate with> Varnish on the backend.>> Check out Pound:>> http://www.apsis.ch/pound/>>On 3/3/08, Per Andreas Buer <perbu at linpro.no> wrote:> > Dag-Erling Sm?rgrav skrev:
> > >
> > > Actually, it would be very complicated...
> >
> > Oh. I guess I'm wrong, then. I though it was the simple matter of
> > linking in some SSL library and let it do its magic. Whats the complication?
> >
> >
> > Per.
> > _______________________________________________
> > varnish-dev mailing list
> > varnish-dev at projects.linpro.no> > http://projects.linpro.no/mailman/listinfo/varnish-dev> >







____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

Per Andreas Buer <perbu at linpro.no> writes:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
> > Actually, it would be very complicated...
> Oh. I guess I'm wrong, then. I though it was the simple matter of
> linking in some SSL library and let it do its magic. Whats the
> complication?

We would need to add a translation layer between the code that talks
to the client and the code that handles requests. The former is not
entirely centralized, so some cleanup would be required. Performance
would suffer, possibly even in the non-SSL case.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Per Andreas Buer <perbu at linpro.no> writes:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
> > Actually, it would be very complicated...
> Oh. I guess I'm wrong, then. I though it was the simple matter of
> linking in some SSL library and let it do its magic. Whats the
> complication?

We would need to add a translation layer between the code that talks
to the client and the code that handles requests. The former is not
entirely centralized, so some cleanup would be required. Performance
would suffer, possibly even in the non-SSL case.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Louis Luo <lluo_2wire at yahoo.com> writes:
> BTW, some ticket mentioned that compression would be added to 2.0.
> How is it now? I need this feature badly. Do you guys have some
> early work that I can try?

That was a wishlist item, not a promised feature. However, Varnish 2.0
supports Vary, so if can enable compression on your backend, it will
"just work" - but DO NOT UNDER ANY CIRCUMSTANCES use the sample
configuration at the top of Apache's mod_deflate documentation, as it
will effectively make every compressable document uncacheable.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Louis Luo <lluo_2wire at yahoo.com> writes:
> BTW, some ticket mentioned that compression would be added to 2.0.
> How is it now? I need this feature badly. Do you guys have some
> early work that I can try?

That was a wishlist item, not a promised feature. However, Varnish 2.0
supports Vary, so if can enable compression on your backend, it will
"just work" - but DO NOT UNDER ANY CIRCUMSTANCES use the sample
configuration at the top of Apache's mod_deflate documentation, as it
will effectively make every compressable document uncacheable.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Thanks for your info. But do you mean Varnish 2.0 won't support compression by itself, but rely on the backend to compress HTML pages? If so, then can it cache compressed pages?


I need to offload the compression work from backend to the proxy, so probably cannot take advantage of this Vary feature. I was wondering how much work there would be to add this compression feature. If this is not that challenging, our team might do some work to port lighty's mod_deflate to Varnish, if that won't conflict with your plan.


Thanks.


L.
> That was a wishlist item, not a promised feature. However, Varnish 2.0 supports Vary, so if can enable compression on your backend, it will "just work" - but DO NOT UNDER ANY CIRCUMSTANCES use the sample configuration at the top of Apache's mod_deflate documentation, as it will effectively make every compressable document uncacheable. DES




____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Thanks for your info. But do you mean Varnish 2.0 won't support compression by itself, but rely on the backend to compress HTML pages? If so, then can it cache compressed pages?


I need to offload the compression work from backend to the proxy, so probably cannot take advantage of this Vary feature. I was wondering how much work there would be to add this compression feature. If this is not that challenging, our team might do some work to port lighty's mod_deflate to Varnish, if that won't conflict with your plan.


Thanks.


L.
> That was a wishlist item, not a promised feature. However, Varnish 2.0 supports Vary, so if can enable compression on your backend, it will "just work" - but DO NOT UNDER ANY CIRCUMSTANCES use the sample configuration at the top of Apache's mod_deflate documentation, as it will effectively make every compressable document uncacheable. DES




____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Louis Luo <lluo_2wire at yahoo.com> writes:
> Thanks for your info. But do you mean Varnish 2.0 won't support
> compression by itself, but rely on the backend to compress HTML pages?
> If so, then can it cache compressed pages?

Yes, and yes.

> I need to offload the compression work from backend to the proxy

Why? A properly configured cache should reduce the backend load to a
point where you can afford compression.

> so probably cannot take advantage of this Vary feature. I was
> wondering how much work there would be to add this compression
> feature. If this is not that challenging, our team might do some work
> to port lighty's mod_deflate to Varnish, if that won't conflict with
> your plan.

Compression itself is easy. The hard part is figuring out when and how
to do it; ideally, we should compress a document only if and only if we
get a request from a client that supports compression, and when we do,
we should cache it with the same ttl as the original object. I imagine
that some of the mechanisms that were introduced to support Vary can
also be used to support native compression.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Louis Luo <lluo_2wire at yahoo.com> writes:
> Thanks for your info. But do you mean Varnish 2.0 won't support
> compression by itself, but rely on the backend to compress HTML pages?
> If so, then can it cache compressed pages?

Yes, and yes.

> I need to offload the compression work from backend to the proxy

Why? A properly configured cache should reduce the backend load to a
point where you can afford compression.

> so probably cannot take advantage of this Vary feature. I was
> wondering how much work there would be to add this compression
> feature. If this is not that challenging, our team might do some work
> to port lighty's mod_deflate to Varnish, if that won't conflict with
> your plan.

Compression itself is easy. The hard part is figuring out when and how
to do it; ideally, we should compress a document only if and only if we
get a request from a client that supports compression, and when we do,
we should cache it with the same ttl as the original object. I imagine
that some of the mechanisms that were introduced to support Vary can
also be used to support native compression.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Dag-Erling Sm?rgrav wrote:
> Louis Luo <lluo_2wire at yahoo.com> writes:
>> BTW, some ticket mentioned that compression would be added to 2.0.
>> How is it now? I need this feature badly. Do you guys have some
>> early work that I can try?
>
> That was a wishlist item, not a promised feature. However, Varnish 2.0
> supports Vary, so if can enable compression on your backend, it will
> "just work" - but DO NOT UNDER ANY CIRCUMSTANCES use the sample
> configuration at the top of Apache's mod_deflate documentation, as it
> will effectively make every compressable document uncacheable.

You mean

"AddOutputFilterByType DEFLATE text/html text/plain text/xml"

Why will that make documents uncacheable?

Would be sad for non-gzipable browser, but that would be fixed by

"Header append Vary User-Agent"

Or?


--
Audun


*****************************************************************
Denne fotnoten bekrefter at denne e-postmeldingen ble
skannet av MailSweeper og funnet fri for virus.
*****************************************************************
This footnote confirms that this email message has been
swept by MailSweeper for the presence of computer viruses.
*****************************************************************

Dag-Erling Sm?rgrav wrote:
> Louis Luo <lluo_2wire at yahoo.com> writes:
>> BTW, some ticket mentioned that compression would be added to 2.0.
>> How is it now? I need this feature badly. Do you guys have some
>> early work that I can try?
>
> That was a wishlist item, not a promised feature. However, Varnish 2.0
> supports Vary, so if can enable compression on your backend, it will
> "just work" - but DO NOT UNDER ANY CIRCUMSTANCES use the sample
> configuration at the top of Apache's mod_deflate documentation, as it
> will effectively make every compressable document uncacheable.

You mean

"AddOutputFilterByType DEFLATE text/html text/plain text/xml"

Why will that make documents uncacheable?

Would be sad for non-gzipable browser, but that would be fixed by

"Header append Vary User-Agent"

Or?


--
Audun


*****************************************************************
Denne fotnoten bekrefter at denne e-postmeldingen ble
skannet av MailSweeper og funnet fri for virus.
*****************************************************************
This footnote confirms that this email message has been
swept by MailSweeper for the presence of computer viruses.
*****************************************************************

Audun Ytterdal <ay at vg.no> writes:
> Dag-Erling Sm?rgrav wrote:
> > That was a wishlist item, not a promised feature. However, Varnish 2.0
> > supports Vary, so if can enable compression on your backend, it will
> > "just work" - but DO NOT UNDER ANY CIRCUMSTANCES use the sample
> > configuration at the top of Apache's mod_deflate documentation, as it
> > will effectively make every compressable document uncacheable.
>
> You mean
>
> "AddOutputFilterByType DEFLATE text/html text/plain text/xml"
>
> Why will that make documents uncacheable?

No, that part is fine. I was referring to the "Compress everything
except images" example right below it.

> Would be sad for non-gzipable browser, but that would be fixed by
>
> "Header append Vary User-Agent"

Absolutely not. This will force Varnish to cache a separate copy of the
document for every single User-Agent string it encounters.

Browsers that do not support gzip or deflate do not need special
treatment: they do not send Accept-Encoding: and will therefore get an
uncompressed version of the page.

The only browsers that advertise gzip / deflate support but do not
actually support it (and therefore need the BrowserMatch rules) are
early versions of Netscape 4. According to thecounter.com's December
2007 statistics, Netscape 4's market share is 0.00067 - less than one in
one thousand.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Audun Ytterdal <ay at vg.no> writes:
> Dag-Erling Sm?rgrav wrote:
> > That was a wishlist item, not a promised feature. However, Varnish 2.0
> > supports Vary, so if can enable compression on your backend, it will
> > "just work" - but DO NOT UNDER ANY CIRCUMSTANCES use the sample
> > configuration at the top of Apache's mod_deflate documentation, as it
> > will effectively make every compressable document uncacheable.
>
> You mean
>
> "AddOutputFilterByType DEFLATE text/html text/plain text/xml"
>
> Why will that make documents uncacheable?

No, that part is fine. I was referring to the "Compress everything
except images" example right below it.

> Would be sad for non-gzipable browser, but that would be fixed by
>
> "Header append Vary User-Agent"

Absolutely not. This will force Varnish to cache a separate copy of the
document for every single User-Agent string it encounters.

Browsers that do not support gzip or deflate do not need special
treatment: they do not send Accept-Encoding: and will therefore get an
uncompressed version of the page.

The only browsers that advertise gzip / deflate support but do not
actually support it (and therefore need the BrowserMatch rules) are
early versions of Netscape 4. According to thecounter.com's December
2007 statistics, Netscape 4's market share is 0.00067 - less than one in
one thousand.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no