inevity / lusca-cache

Automatically exported from code.google.com/p/lusca-cache
0 stars 0 forks source link

storeurl_rewrite always miss with vary objects #28

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
patch here -> http://www.squid-cache.org/bugs/show_bug.cgi?
id=2678&GoAheadAndLogIn=1

vary objects can now cache HIT but when squid restarted all vary objects will 
became mismatch.

remedy: don't restart squid until its fixed. or don't use storeurl for vary 
objects.

Original issue reported on code.google.com by chudy.fernandez on 5 Jun 2009 at 12:37

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
is the bug ?

2010/04/08 08:54:53| clientTryParseRequest: FD 47 (10.10.10.4:1714) Invalid 
Request
2010/04/08 13:55:19| storeLocateVary: Not our vary marker object,
AB9885DE5910AC378C100FD7DFC1E7DC =
'http://static.ak.connect.facebook.com/connect.php/id_ID/css/bookmark-button-css
/connect-button-css/share-button-css/FB.Connect-css/connect-css',
'accept-encoding="gzip,deflate"'/'-'
2010/04/08 20:34:31| httpAccept: FD 17: accept failure: (53) Software caused
connection abort

Original comment by tembokg...@gmail.com on 8 Apr 2010 at 6:19

GoogleCodeExporter commented 9 years ago
This might fix but not for ICP,HTCP.

Original comment by chudy.fernandez on 24 May 2010 at 4:06

Attachments:

GoogleCodeExporter commented 9 years ago
thx sir, its work

Regards,

F S.

Original comment by fahmi...@gmail.com on 24 May 2010 at 4:43

GoogleCodeExporter commented 9 years ago
Any update? 
I will apply this patch, but I wish it were already in svn ...
Not help much because I understand more than C++, but I'll take a look when I 
get a break

Original comment by osmano...@gmail.com on 3 Jun 2010 at 3:00

GoogleCodeExporter commented 9 years ago
Looking at this and other storeurl related stuff is on my todo list. I just have
other priorities right now. The problem with storeurl and icp/htcp/vary/etc is
figuring out exactly what the behaviour SHOULD be, before committing this sort 
of
stuff. :)

Original comment by adrian.c...@gmail.com on 3 Jun 2010 at 7:30