Chris Hoess wrote:
> 
> In article <[EMAIL PROTECTED]>, JTK wrote:
> > Pratik wrote:
> >>
> >> Nope. Thats just the way websniffer displays it
> >> (http://webtools.mozilla.org/web-sniffer/). Thats not the fault.
> >>
> >
> >
> > Is the cache and specifically the headers written thereto plaintext?  If
> > so, I upgrade my WAG to a WAH (wild-ass hypothesis).
> >
> 
> CR-LF's are the standard line-end in HTTP transactions and omitting one or
> the otherwould in fact be considered a violation of the standards
> (although we probably play ball with that).  They're quite widespread.
>

No I know.  What causes all peoples of the world endless grief is the
fact that Unii C runtimes think all *files* are text files, wheras in
the Windows world (at least), C runtimes realize that all files *aren't*
text files any more than all files are jpegs or HTML or executables or
whatever.  So what happens on an all-too-regular basis is that a Unii
programmer will go fseeking around an actual text file as if it were a
binary file with a 1-to-1 correspondence between characters (including
line endings, formatting controls, etc) and bytes, which isn't the case
on Windows, or for that matter with Unicode or MBCS encoding, etc.

So, let's say you have the binary image of the header in question in a
buffer, CR's and all, and Joe Linux wants to write it to the cache. 
Well mercy, we can't have a "Windows" file on a Unix system!  So he
writes it stripped of it's CRs - to a file opened "fwrite("name",
"w");".  Then he can fseek all around, picking out individual characters
if he so chooses, and everything's copacetic - until he tries the same
thing on Windows.  That naked "w" adds back the CRs and havoc ensues and
I see yesterday's news.  He should have either used "wb" or not tried to
fseek in a text file expecting a 1:1 character:byte relationship.

So, my WAT (wild-ass theory now) is that the letter "b" will solve this
problem.
 
> Incidentally, are you running any filters on Proxomitron?

Sure, isn't that kinda the idea? ;-)

>  There was one
> bug filed by someone experiencing problems similar to yours, but the
> reporter wasn't able to reproduce it on other machines, and it went away
> after a cold install (of Mozilla?  Proxomitron?).  See bug 100075 for
> details.
>

Well again, I run IE through the same exact Proxomitron, and view the
exact same CNN, and get two different behaviors.  Either two programs
are broken in such a way that the errors cancel each other out, or one
program has a broken cache.
 
> --
> Chris Hoess

Reply via email to