The second response is a response to an expected follow up request on the same connection (using keep alive). If you're seeing it as part of the response on the first request then it's either an issue with the client not handling keep alive connections correctly, or an issue with the content length of the first response (need to verify that enough bytes were actually sent, can't do it with this trace dump).
Thanks, Yehuda On Mon, Jun 16, 2014 at 8:47 AM, Sylvain Munaut <s.mun...@whatever-company.com> wrote: > Hi, > > We're testing the civetweb frontend currently and there is an > intermitent issue where the response will contain an extraneous 'ERROR > 500' response mixed in. > > > This is a tcpdump from such an occurent. > > > ----- > GET / HTTP/1.1 > User-Agent: curl/7.30.0 > Host: s3.svc:81 > Accept: */* > > HTTP/1.1 200 OK > Content-type: application/xml > Content-Length: 214 > > <?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult > xmlns="http://s3.amazonaws.com/doc/2006-03-01/";><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>HTTP/1.1 > 500 Server Error > Content-Length: 48 > Date: Mon, 16 Jun 2014 15:21:47 GMT > Connection: keep-alive > > Error 500: Server Error > Client closed connection > ----- > > As you can see there is the perfectly valid response present to the > query and then there is another response that somehow ended up in the > same connection for no reason at all ... > > Unfortunately I have not been able so far to reproduce it in a > synthetic test, so I'm not sure exactly how to trigger it. > > > Cheers, > > Sylvain > _______________________________________________ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
