In message <49945b51.90...@progis.de>, Andreas Fassl writes:
>Hi, especially the caching is very important for us, because we want to
>keep traffic away from the mp3 repository server.
>So you recommend:
>Client requests streaming on demand mp3
>- lighthttpd does streaming and requests from
>- va
Hi, especially the caching is very important for us, because we want to
keep traffic away from the mp3 repository server.
So you recommend:
Client requests streaming on demand mp3
- lighthttpd does streaming and requests from
- varnish as reverse proxy/cache from
- mp3 repository
Best regards
A
On Feb 12, 2009, at 3:34 AM, Poul-Henning Kamp wrote:
> Well, if people in general think our defaults should be that way, we
> can change them, our defaults are whatever the consensus can agree on.
I'm with the OP. Regardless of the finer details of the RFC, if I'm a
web developer and I set the
Ole Laursen writes:
> just a matter of having enough RAM to keep the requested data in memory. For
> this reason, I don't think there's any point in using Varnish's cache in this
> kind of setup.
In other words, unless you need some other feature of Varnish, you might as well
route the requests
Andreas Fassl writes:
> after reading the docs it looks like I need an apache server to serve
> the cached mp3 content for streaming on demand.
> Any experience in configuration of this setup?
No, but I have set up a site with videos streamed with a Flash widget. We let
the video files pass thr
]] Rob Ayres
| Does anyone have an idea what has caused this?
Not really, no. I'm going to get a buildbot slave going on Solaris so
we'll hopefully be able to avoid such bugs in the future. If you have
found a solution, patches are more than welcome.
--
Tollef Fog Heen
Redpill Linpro -- Cha
]] Florian Gilcher
| So, I am beginning to wonder on how esi:include is implemented in
| varnish or what I am doing wrong. Because - granted - the ESI
| specification could be interpreted to include the element without
| giving much thought on what the returned entity actually represents.
Poul-Henning Kamp writes:
> If you look *really* carefully through the RFC2616, you will find one
> reference to server side caches -- which they forgot to remove.
I get your point (the RFC doesn't apply to Varnish). It wasn't my intention to
slam Varnish for standards violation, though, sorry if
In message , Ole Laursen writes:
>Poul-Henning Kamp writes:
>
>> We don't consider varnish a "shared cache" in the RFC2616 sense of
>> the concept, because the varnish instance is fully under the control
>> of the servers administrator, and should therefore be considered
>> part of the server.
>
>
Poul-Henning Kamp writes:
> We don't consider varnish a "shared cache" in the RFC2616 sense of
> the concept, because the varnish instance is fully under the control
> of the servers administrator, and should therefore be considered
> part of the server.
As I read that part of the RFC, shared si
In message , Ole Laursen writes:
>Poul-Henning Kamp writes:
>I looked up private here
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
>
>and it says
>
>Indicates that all or part of the response message is intended
>for a single user and MUST NOT be cached by a shared cache.
Poul-Henning Kamp writes:
> In message , Ole Laursen writes:
>
> >Why doesn't Varnish respect Cache-Control: private and Cache-Control:
> >no-cache
> >out of the box?
>
> Because we see those as headers you want non-friendly caches to act on,
> whereas we consider Varnish a friendly cache, unde
In message , Ole Laursen writes:
>Why doesn't Varnish respect Cache-Control: private and Cache-Control: no-cache
>out of the box?
Because we see those as headers you want non-friendly caches to act on,
whereas we consider Varnish a friendly cache, under your control.
Poul-Henning
--
Poul-Henni
13 matches
Mail list logo
