[EMAIL PROTECTED] (Boris Zbarsky) wrote: > > Sorry about the delay, the real world intruded. > > Likewise. >
More real world. Sorry again for the delay. > > BeOS is just one OS. Mozilla is supposed to be multi-platform and names > > are relevant on some platforms. > > So? My point was that the thinking behind "accept" was not predicated on the > assumption that the file type is determined by the filename, as your mail > implied. > What I was trying to say is that, except possibly for BeOS, using filenames (more precisely, filename suffixes) or examining actual content is necessary to implement "accept" and this can be expensive. I was also hinting that getting a reasonable behavior in almost all cases is hard. For example, if there are no matching files do you display nothing to the user or do you display everything and also tell the user that there are no matches? Do you list all the URL's "accept" options for the user? Will the user understand any of this? Will the user care? If the user forces a selection do you use the mime type you think is right or do you ask the user to select one from the URL's list? Since "accept" is not mandated, it seems easier to just ignore it. > > > In 99.99% of cases, the file type will in fact not be changing any time > > > soon. Let's not call things "useless" when they are at worst slightly > > > unreliable. > > > > Oh, let's. If treating the common case were the only requirement then > > mozilla would have a lot fewer tests for null this and negative that. > > Nice straw man. If a null check is neglected, the application crashes. What > goes wrong if the wrong content-type is sniffed, exactly? That's what we have > to consider when implementing any sniffing algorithm. > It's not a matter of the wrong mime type, it's a matter of the wrong file. I'm saying that once mozilla (or any of the fowl) choose to use a file it should grab the file and hold it until it's through with it. For a unix system where an open file can have no name there are a few extra wrinkles but there are known ways to address this. I'm saying that mozilla should not skip steps just because the steps aren't usually necessary. To me this is the same thing as null checks, etc. > > Frankly, I fail to see why virii/worms would be an issue whn uploading; > further, I fail to see how content-type sniffing affects them being an issue. > Please be so kind as to explain the problem clearly instead of making cryptic > pronouncements. > The user assumes that what is actually uploaded is the same as the original local file. It would be disastrous for mozilla-s reputation if it were possible to alter a file before it's actually sent. If someone has tested and someone else has verified that, from the time the user chooses a file to the time it's sent out on the wire, nothing in the mozilla run-time can observe that such a transaction has started and nothing can interfere with or alter that transaction until it's completed then I'll believe mozilla is reasonably secure. and I think one of the necessary conditions for this is that mozilla be extremely careful handling files. If something could do this, then it would, of course, be a virus or worm. > > Also, "useless" was referring to opening a bunch of files just to see > > what's in them. Also (again), "accept" support seems to be optional so I'm > > not sure this is something worth pursuing at this time. > > That s a separate issue entirely. The question on the table is what APIs the > network library and XPCOM should expose to consumers; how consumers use these > APIs is a separate matter. > > In particular, stream objects in Mozilla do not have a type associated with > them. Perhaps this is what should really be fixed? > I wouldn't object to associated types as long as there's a distinction between a stream of unknown type which is treated as a default type and a stream that actually is the default type. Would typing a stream require a push-back buffer of a rather large size? > > Presumably headers are in a memory buffer so you just stuff that down the > > network socket first, then you read from the file stream and just start > > stuffing that into the socket. I don't see a problem. > > I suggest you give the form submission code a read... Basically, we need the > type before we start reading the stream there. > OK, give me a few hints of where to start looking. It seems odd, though. Can't you just attach a data block containing all this ancillary stuff to a stream and just output that block first? > Boris > > P.S. Again, I am on the list, so no need to cc me on replies; especially if > your mail client generates messages with two different message IDs in the > process. Well, you started it. :-) You sent me email in your response to my first reply so I just continued the practice. As for the ids, blame Communicator 4.8 and various mailers. It wasn't intentional.
