It would be really helpful if someone from the AVAST team could comment here - it would probably save a lot of ping-pong.
On Tue, Dec 2, 2008 at 12:02 PM, libor
<liborhavlicek%2Bdwrforum@...> wrote:
Thanks, for reply Joe.
I have good and bad news. Bad news are, that "Transfer-Encoding:chunked"
gives not enought information for avast team, because it only says, that the
length of transfered data is unknown at beginning.
I have to say, I think this is being done the wrong way around.
Surely it would be better to assume that chunked mode meant drip-feed, and the special case things like compression (which are easy to detect) rather than to assume chunked mode didn't exist (which it clearly does) and special case a growing set of services that are hard to detect. Today it's Lightstreamer, DWR, Google, Facebook, Jetty, Perbal, etc, etc, etc but I expect the list will grow.
So it is hudge technical
problem to deside if functionality of web depends on if the chunk is
received imediatelly or not. They will not accept chunged word as keyword
for comet.
Now good news. They were so kind, that they offered me to detect DWR comet
by
"Server: DWR-Reverse-Ajax ...." if string prefix for Server attribute in
response header starts with "DWR-Reverse-Ajax" substring, thay will detect
it, and stop blocking reverse ajax.
So are we saying that AVAST will whitelist anything with this growing list of server names?
Isn't this a huge security hole?
So for now this is hotfix. The Avast update will be released today.
They told me, thay you DWR team should deside how to describe that this
response is COMET. For example by "Content-Type: COMET", and you should add
it to next release, so antivirus and firewall companies could recognise it
and fixe this problem universally.
Except that the content type isn't COMET. COMET isn't event a valid value for the Content-Type header. Our content type is text/javascript.
Changing this would break the security of systems that are examining DWR content.
I took a look to see what Google was doing, and found this header:
X-Content-Type-Options: nosniff
If this *requires* a header, then I'd be far happier if the header was something like this that was not subverting the meaning of something else.
Joe.
