What are you looking at and why is it such a big deal?
Not a big deal really, just interesting to a certain kind of warped mind ;)
The second number-- the one after the 300 or 403 or whatever-- is the total size of the file your server sent in response to the request. In fact you've got a beautifully illustrative snippet there.
The request for the index page comes through as no size at all; can I assume you've got the host redirecting requests that don't have "www" the way you like it?
The 403 also comes through as no size at all, although this one is your own 403 based on your own htaccess rules. Interesting. Guess it didn't even pretend to read your 403 page, assuming you've got one.
The request for /storefront is a directory-slash redirect. Bing seems to be fond of those too, as if they're actively seeking out Duplicate Content. (You may not know about this category of redirect. It happens automatically through the kind graces of mod_dir unless you have explicitly told it not to.) This one has to go all the way down to your site to verify that the directory exists, so somewhere along the line it picked up 249 bytes. Part of that may be the formal filename.
The third line /storefront/ is the actual size of your page, plus a bit for headers and so on. If the size had been, say, less than 1000, we'd assume the asker was getting rewritten to some custom error page. Rewrites come through as 200 (or 304); filesize is the only clue your logs give you.
And now you see where the 85 is coming from. I didn't notice before that it's xml rather than plain txt, so 85 may again be the actual filesize. You can easily check.
Lesson: no two servers count bytes the same way.
