2014-10-30 10:42 GMT+01:00 Mark Thomas <ma...@apache.org>: > Was it just the cost of the chunking that triggered this change or was > it something else? If it was performance, how much difference does this > change make? >
Debugging something else, this turned out to not cause a failure, it was the reversed header order that caused the problem. > > Looking at the code, I can see a couple of places where this changes > behaviour: > - If the client requests the connection is closed > Yes, that was this situation, the client sends a connection close. But in that case connection close is also added to the response (right after this code) so the behavior is consistent. > - If the request is the last one before the connection is closed due to > reaching the maximum number of keep-alive requests > > We have had bug reports in the past about not being able to detect a > truncated response. I suspect the current unit tests for those miss the > second case above which is my main concern right now. > > I don't think a system property is the right way to handle configuration > of this feature (if such configuration is required). There is no reason > it could not be a connector attribute. > IMO the new attribute should also do the same thing for connection close in the response. The default should be to not chunk if closing (as is right now). Ok, so since you're complaining about every commit, next fix you'll scream more since the upgrade process is not correct (no handling of leftover input bytes, anything included in the same packet that the request header is lost - I would agree it's questionable client behavior though). This means adding code to pass around a ByteBuffer to the upgraded processor to add as input since I see no other way :) Yum. Rémy
