Re: Conditional caching question
In message [EMAIL PROTECTED], David Pratt writes: Hi. Sorry for not getting back sooner. The use case I have is have backend determine when frequency reaches a threshold and set ttl dynamically based on the rate. [...] And Varnish is a perfect frontend for that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: guru meditation errors on timeouts?
In message [EMAIL PROTECTED], Wichert Akkerman writes: We've upgraded to current varnish trunk but are seeing a fair number of guru meditation errors appear. My hunch is that those appear when the backend server takes too long to respond. Is there a way to verify that and to change the used timeout? Do you have a varnishlog where this happens ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: guru meditation errors on timeouts?
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Wichert Akkerman writes: We've upgraded to current varnish trunk but are seeing a fair number of guru meditation errors appear. My hunch is that those appear when the backend server takes too long to respond. Is there a way to verify that and to change the used timeout? Do you have a varnishlog where this happens ? I do now: 12 SessionOpen c 10.121.10.84 53022 12 ReqStart c 10.121.10.84 53022 1318563041 12 RxRequestc GET 12 RxURLc /nordic/elkjop-datter/sectors/ce/newsletter 12 RxProtocol c HTTP/1.1 12 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; nb-no) AppleWebKit/525.18 (KHTML, like Gecko) Version/ 3.1.1 Safari/525.20 12 RxHeader c Referer: http://plone.elkjop.int/nordic/elkjop-datter/sectors/ce 12 RxHeader c Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 12 RxHeader c Accept-Language: nb-no 12 RxHeader c Accept-Encoding: gzip, deflate 12 RxHeader c Cookie: tree-s=eJzTyCkw5NLIKTDiClZ3hALXLEdbda4CY65EoIQJSNYUSdYjPBIka8aVCAR6AAoUED0; mainchain=943ed3c25e6d44497de b3fe274f98a96; _ZopeId=94470895A3ZdBnkIwXc; __ac=###= 12 RxHeader c Connection: keep-alive 12 RxHeader c Host: plone.elkjop.int 12 VCL_call c recv 12 VCL_return c lookup 12 VCL_call c hash 12 VCL_return c hash 12 VCL_call c miss 12 VCL_return c fetch 13 TxRequestb GET 13 TxURLb /VirtualHostBase/http/plone.elkjop.int:80/eli/VirtualHostRoot/nordic/elkjop-datter/sectors/ce/newsletter 13 TxProtocol b HTTP/1.1 13 TxHeader b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; nb-no) AppleWebKit/525.18 (KHTML, like Gecko) Version/ 3.1.1 Safari/525.20 13 TxHeader b Referer: http://plone.elkjop.int/nordic/elkjop-datter/sectors/ce 13 TxHeader b Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 13 TxHeader b Accept-Language: nb-no 13 TxHeader b Accept-Encoding: gzip, deflate 13 TxHeader b Cookie: tree-s=eJzTyCkw5NLIKTDiClZ3hALXLEdbda4CY65EoIQJSNYUSdYjPBIka8aVCAR6AAoUED0; mainchain=943ed3c25e6d44497de b3fe274f98a96; _ZopeId=94470895A3ZdBnkIwXc; __ac=###= 13 TxHeader b Host: plone.elkjop.int 13 TxHeader b X-Varnish: 1318563041 13 TxHeader b X-Forwarded-For: 10.121.10.84 13 BackendClose b lb01 12 VCL_call c fetch 0 Debug- VCL_error(0, (null)) 12 VCL_return c error 12 SessionClose c error returned 12 TxProtocol c HTTP/1.0 12 TxStatus c 503 12 TxResponse c Service Unavailable 12 TxHeader c Date: Mon, 09 Jun 2008 13:56:24 GMT 12 TxHeader c Server: Varnish 12 TxHeader c Retry-After: 0 12 TxHeader c Content-Type: text/html; charset=utf-8 12 TxHeader c X-Varnish: 1318563041 12 TxHeader c Connection: close 12 ReqEnd c 1318563041 1213019784.562031031 1213019784.562954903 0.032984257 nan nan -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange Opera error in POST
Ok, I have gathered some more info about the problem.
What I have is a form login that has 3 input fields, username, password
and security code (from captcha).
When opera is making the POST it receives a 200 OK and NOT a 302 Moved
Temp. as expected.
This is the request that Opera is making:
13 RxRequestc POST
13 RxURLc /takelogin.php
13 RxProtocol c HTTP/1.1
13 RxHeader c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
13 RxHeader c Host: mydomain.com:8080
13 RxHeader c Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1
13 RxHeader c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
13 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
13 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
13 RxHeader c Referer: http://mydomain.com:8080/login.php
13 RxHeader c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
13 RxHeader c Cookie2: $Version=1
13 RxHeader c Connection: Keep-Alive, TE
13 RxHeader c TE: deflate, gzip, chunked, identity, trailers
13 RxHeader c Content-Length: 63
13 RxHeader c Content-Type: application/x-www-form-urlencoded
My vcl has this code when POST are received:
if(req.request != GET req.request != HEAD) {
set req.http.Connection = close;
pass;
}
This code usually works with FF and IE but NOT with Opera.
If I remove set req.http.Connection = close;
the login process works with no problem.
I have had problems with POSTs before, thats why I've been using
Connection = close on POSTs.
Here is the whole error log:
0 CLI - Rd ping
0 CLI - Wr 0 200 PONG 1213029670
13 SessionClose - timeout
13 StatSess - 82.182.xx.xx 1306 0 1 2 0 0 2 744 6750
0 CLI - Rd ping
0 CLI - Wr 0 200 PONG 1213029673
13 SessionOpen c 82.182.xx.xx 1307 0.0.0.0:8080
13 ReqStart c 82.182.xx.xx 1307 803913450
13 RxRequestc POST
13 RxURLc /takelogin.php
13 RxProtocol c HTTP/1.1
13 RxHeader c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
13 RxHeader c Host: mydomain.com:8080
13 RxHeader c Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1
13 RxHeader c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
13 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
13 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
13 RxHeader c Referer: http://mydomain.com:8080/login.php
13 RxHeader c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
13 RxHeader c Cookie2: $Version=1
13 RxHeader c Connection: Keep-Alive, TE
13 RxHeader c TE: deflate, gzip, chunked, identity, trailers
13 RxHeader c Content-Length: 63
13 RxHeader c Content-Type: application/x-www-form-urlencoded
13 VCL_call c recv
13 VCL_return c pass
13 VCL_call c pass
13 VCL_return c pass
14 TxRequest- POST
14 TxURL- /takelogin.php
14 TxProtocol - HTTP/1.1
14 TxHeader - User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
14 TxHeader - Host: mydomain.com:8080
14 TxHeader - Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1
14 TxHeader - Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
14 TxHeader - Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
14 TxHeader - Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
14 TxHeader - Referer: http://mydomain.com:8080/login.php
14 TxHeader - Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
14 TxHeader - Cookie2: $Version=1
14 TxHeader - Content-Type: application/x-www-form-urlencoded
14 TxHeader - X-Varnish: 803913450
14 TxHeader - X-Forwarded-For: 82.182.xx.xx
14 RxProtocol - HTTP/1.1
14 RxStatus - 200
14 RxResponse - OK
14 RxHeader - Date: Mon, 09 Jun 2008 16:41:14 GMT
14 RxHeader - Server: Apache
14 RxHeader - X-Powered-By: PHP/5.2.0-8+etch10
14 RxHeader - Content-Length: 23
14 RxHeader - Content-Type: text/html; charset=UTF-8
13 ObjProtocol c HTTP/1.1
13 ObjStatusc 200
13 ObjResponse c OK
13 ObjHeaderc Date: Mon, 09 Jun 2008 16:41:14 GMT
13 ObjHeaderc Server: Apache
13 ObjHeaderc X-Powered-By: PHP/5.2.0-8+etch10
13 ObjHeaderc Content-Type: text/html; charset=UTF-8
14 BackendReuse - mydomain
13 TTL c 803913450 RFC 120 1213029674 1213029674 0 0 0
13 VCL_call c fetch
13 VCL_return c pass
13 Length c 23
13 VCL_call c deliver
13 VCL_return c deliver
13 TxProtocol c HTTP/1.1
13 TxStatus c 200
13 TxResponse c OK
13 TxHeader c Server: Apache
Re: Strange Opera error in POST
In message [EMAIL PROTECTED], Erik Torlen writes:
My vcl has this code when POST are received:
if(req.request != GET req.request != HEAD) {
set req.http.Connection = close;
pass;
}
This code usually works with FF and IE but NOT with Opera.
If I remove set req.http.Connection = close;
the login process works with no problem.
I have had problems with POSTs before, thats why I've been using
Connection = close on POSTs.
I'm not sure I can say much here...
The close trick is mostly, if not only, relevant for pipe mode,
where it prevents more than the first request from the client from
being piped. It doesn't really do anything positive for pass.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange Opera error in POST
Yes, Im aware of that. But I did have some problem in an earlier version
of trunk (and especially 1.1.2), but with the latest it seems better.
I have seen alot of updates on trunk the latest days, what's the status
of it, is it stable for production use?
/ Duja
Poul-Henning Kamp skrev:
In message [EMAIL PROTECTED], Erik Torlen writes:
My vcl has this code when POST are received:
if(req.request != GET req.request != HEAD) {
set req.http.Connection = close;
pass;
}
This code usually works with FF and IE but NOT with Opera.
If I remove set req.http.Connection = close;
the login process works with no problem.
I have had problems with POSTs before, thats why I've been using
Connection = close on POSTs.
I'm not sure I can say much here...
The close trick is mostly, if not only, relevant for pipe mode,
where it prevents more than the first request from the client from
being piped. It doesn't really do anything positive for pass.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange Opera error in POST
What I should mention is that the problem can be solved by another method.
If I remove the Cookie2 AND TE header it all works out fine:
remove req.http.Cookie2;
remove req.http.TE;
if(req.request != GET req.request != HEAD) {
set req.http.Connection = close;
pass;
}
This works!
But I must remove BOTH Cookie2 and TE header, else it wont work.
/ Duja
Poul-Henning Kamp skrev:
In message [EMAIL PROTECTED], Erik Torlen writes:
My vcl has this code when POST are received:
if(req.request != GET req.request != HEAD) {
set req.http.Connection = close;
pass;
}
This code usually works with FF and IE but NOT with Opera.
If I remove set req.http.Connection = close;
the login process works with no problem.
I have had problems with POSTs before, thats why I've been using
Connection = close on POSTs.
I'm not sure I can say much here...
The close trick is mostly, if not only, relevant for pipe mode,
where it prevents more than the first request from the client from
being piped. It doesn't really do anything positive for pass.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange Opera error in POST
Can I get you to record a varnish log where you do that and one
where you don't, and then open a ticket with this issue ?
Poul-Henning
In message [EMAIL PROTECTED], Erik Torlen writes:
What I should mention is that the problem can be solved by another method.
If I remove the Cookie2 AND TE header it all works out fine:
remove req.http.Cookie2;
remove req.http.TE;
if(req.request != GET req.request != HEAD) {
set req.http.Connection = close;
pass;
}
This works!
But I must remove BOTH Cookie2 and TE header, else it wont work.
/ Duja
Poul-Henning Kamp skrev:
In message [EMAIL PROTECTED], Erik Torlen writes:
My vcl has this code when POST are received:
if(req.request != GET req.request != HEAD) {
set req.http.Connection = close;
pass;
}
This code usually works with FF and IE but NOT with Opera.
If I remove set req.http.Connection = close;
the login process works with no problem.
I have had problems with POSTs before, thats why I've been using
Connection = close on POSTs.
I'm not sure I can say much here...
The close trick is mostly, if not only, relevant for pipe mode,
where it prevents more than the first request from the client from
being piped. It doesn't really do anything positive for pass.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
