Re: 400 error on cookie string

2017-01-05 Thread cas 
Get one strange error that I never seen before   Total events captured on [05/Jan/2017:09:13:56.054] : 12
 
[05/Jan/2017:09:09:06.594] frontend http-in (#3): invalid request
  backend  (#-1), server  (#-1), event #11
  src 70.192.67.217:3224, session #243701, session flags 0x0080
  HTTP msg state 26, msg flags 0x, tx flags 0x
  HTTP chunk len 0 bytes, HTTP body len 0 bytes
  buffer flags 0x00808002, out 0 bytes, total 924 bytes
  pending 924 bytes, wrapping at 32768, error at position 902:
 
  0  7B%22distinct_id%22%3A%20%222044eec9-0217-e611-80c1-4c72b97cbdb1%22%2C
  00070+ %22%24initial_referrer%22%3A%20%22%24direct%22%2C%22%24initial_referri
  00140+ ng_domain%22%3A%20%22%24direct%22%2C%22__mps%22%3A%20%7B%7D%2C%22__mps
  00210+ o%22%3A%20%7B%7D%2C%22__mpa%22%3A%20%7B%7D%2C%22__mpu%22%3A%20%7B%7D%2
  00280+ C%22__mpap%22%3A%20%5B%5D%2C%22tref1%22%3A%20%22xmonetize%22%2C%22tref
  00350+ 2%22%3A%20%22emailsmaster%22%2C%22tref3%22%3A%20%22Daily%20Quiz%20%7C%
  00420+ 20Trivia%20Clickers%200-14d%20%7C%208d%2B%20%7C%20Email1%20Theme%20%7C
  00490+ %20ByActivityTime%20%7C%20Categories%20Since%2012%2F28%2F2016%22%2C%22
  00560+ tref4%22%3A%20%22NA%22%2C%22emaildomain%22%3A%20%22gmail.com%22%2C%22l
  00630+ anding%22%3A%20%22default%22%2C%22regdate%22%3A%20%222016-05-10%22%2C%
  00700+ 22tref12%22%3A%20%22facebook-ad%22%2C%22tref13%22%3A%20%22TriviaQuesti
  00770+ ons-2%22%2C%22tref14%22%3A%20%22US6%25VisitorsConv%22%2C%22tref15%22%3
  00840+ A%20%22series%22%2C%22%24search_engine%22%3A%20%22google%22%7D; mp_mix
  00910+ panel__c=1\r\n
  00922  \r\n
  05.01.2017, 09:25, "c...@xmonetize.net" :  Yes, please apply Willy's patch to the 1.7.1 release and tell us what happens. Everything looks good. No errors.   About 1.6.11. It was in the first days of December. May be I've mixed up something.I can test again tomorrow if you want  It was 1.6.10. I think I've made some mistakes in paths so maybe I've started as a service 1.7 and haproxy -vv 1.6. I'm not pro in nix, sorry for confusing you

Re: 400 error on cookie string

2017-01-04 Thread cas 
  Yes, please apply Willy's patch to the 1.7.1 release and tell us what happens. Everything looks good. No errors.   About 1.6.11. It was in the first days of December. May be I've mixed up something.I can test again tomorrow if you want  It was 1.6.10. I think I've made some mistakes in paths so maybe I've started as a service 1.7 and haproxy -vv 1.6. I'm not pro in nix, sorry for confusing you

Re: (Без темы)

2017-01-04 Thread cas 
About 1.6.11. It was in the first days of December. May be I've mixed up something. I can test again tomorrow if you want 04.01.2017, 17:43, "c...@xmonetize.net" <c...@xmonetize.net>: Hi, Thank you very much for fix. I just want to mention that I had this issue in 1.6.11 too.My name is Aleksey Gordeev. I'm glad that my information was useful. Also I will wait any commit, branch or tag to test it. It is very easy to test it.  I found it and fixed it! It was me again who added a bug in 1.7 with the optimizations for largeheaders and large requests. If certain conditions are met, we could readthe \r from previous data (as we guessed) and complain that the next bytewas not an LF once the remaining part arrived. I'm intending to merge the attached patch. "cas", I'm willing to add youas the reporter here since you provided lots of very valuable information,but for this it would be nice if you had a name :-) I'll backport it to 1.7. Unfortunately there's no easy workaround on anexisting configuration, so I'll produce 1.7.2 soon I guess. I'll try toadd the remaining missing information to make dumps more accurate regardingthe expected state (this would definitely had helped here). Cheers,Willy

[no subject]

2017-01-04 Thread cas 
 Hi, Thank you very much for fix. I just want to mention that I had this issue in 1.6.11 too.My name is Aleksey Gordeev. I'm glad that my information was useful. Also I will wait any commit, branch or tag to test it. It is very easy to test it.  I found it and fixed it! It was me again who added a bug in 1.7 with the optimizations for largeheaders and large requests. If certain conditions are met, we could readthe \r from previous data (as we guessed) and complain that the next bytewas not an LF once the remaining part arrived. I'm intending to merge the attached patch. "cas", I'm willing to add youas the reporter here since you provided lots of very valuable information,but for this it would be nice if you had a name :-) I'll backport it to 1.7. Unfortunately there's no easy workaround on anexisting configuration, so I'll produce 1.7.2 soon I guess. I'll try toadd the remaining missing information to make dumps more accurate regardingthe expected state (this would definitely had helped here). Cheers,Willy