Re: Intermittent E_NOINTERFACE error, possibly RPC related

Michael,

Oh, sorry, you were referring to their now current solution of messing with
the Content-Length header in the response, etc.

Yes, they need to get their act together on this one.

Paul

"Paul Baker [MVP, Windows - Networking]" <paulrichardbaker@xxxxxxxxxxxxxxxx>
wrote in message news:esPw6K3WHHA.600@xxxxxxxxxxxxxxxxxxxxxxx
Michael,

Perhaps their absurd solution was necessitated by the fact that they were
unable to modify the request if it involved a change in length.

Would this have implications on the integrity of the network traffic? If
it is at the packet level, could they really get away with changing the
size of the packet? Perhaps not, I don't know enough about that.

Would it have implications on the requirements of their software? It
certainly could. If all their code is written to modify buffers in place
and cannot handle reallocating the buffer if necessary, keeping track of
it, etc. it could end up being a major change that could not be done at
that late stage in development and still meet deadlines.

Not that I believe these are acceptable excuses...

Paul

"Michael K. O'Neill" <MikeAThon2000@xxxxxxxxxxxxxxxxxx> wrote in message
news:%23T9GrJ2WHHA.2284@xxxxxxxxxxxxxxxxxxxxxxx

"Paul Baker [MVP, Windows - Networking]"
<paulrichardbaker@xxxxxxxxxxxxxxxx>
wrote in message news:egwRUe0WHHA.3568@xxxxxxxxxxxxxxxxxxxxxxx
Michael,

Symantec's "Norton Internet Security (NIS)" is so brain-dead that it
can't
figure out HTTP content that has been gzip-compressed. The Symantec
solution, astoudingly, was to change the request header, so that if
your
browser (or, in my case, the client app that I had written) sent a
request
with a "Accept-Encoding: gzip, deflate" header, Symantec changed it
to
"Accept-Encoding: ----, -------" (literally, with the dashes), before
it
let
the request out onto the wire, so as to suppress the server's return
of
gzip'ed content. Their current version of NIS is almost worse:
"WARNING:
New Norton Internet Security Issue" at
http://www.port80software.com/200ok/archive/2006/01/04/901.aspx

I am reading about the Accept-Encoding header for the first time.
However,
my understanding is that if they just changed it to Accept-Encoding
compress:q=0, gzip:q=0, they would prevent the response from being
compressed and solve their perceived problem.


http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3Accept-Encoding

However, they should not consider a compressed response to be a problem.
By
preventing it, they may be breaking an application that requires it
(even
though perhaps it shouldn't). If they really want to scrutinize the
data,
why not decompress it and scrutinize that on the fly?

Is it really that simple?

Paul



Obviously it would be pure speculation for me to guess on the reasons why
Symantec did what it did.

But my reaction at the time when I encountered the problem was exactly
the
same as yours now: They should have left the header and the response
alone,
and internally decompressed the response on the fly when they applied
their
security checking.

My guess as to why they didn't do so, is that they couldn't and still
meet
delivery schedules. They probably encountered the "problem" late in
development, at a point where they couldn't implement on-the-fly
decompression into the then-current architecture.

Even so, that still doesn't explain the absurd "solution" implemented
now,
in their current release of NIS, as detailed at the port80software link I
gave.

Mike






.

Relevant Pages