Mikus, Mikus Grinbergs wrote:
> > tested your bank's server (URL provided by e-mail) with an HTTP/1.1 > > compliance tool ... found that your bank's web server did not support > > pipelining. Unfortunately, that is in violation of the HTTP/1.1 > > specification, RFC2616. > > A perspective on whose standards count in the real world: > > - The bank has many customers. You (usually) have few banks. > > - If the bank doesn't adhere to HTTP standards, a few customers get > annoyed, and the bank's deposits are microscopically impacted > > - If you don't adhere to the bank's standards (whether they violate > HTTP or not), your transaction is not processed -- meaning your > access to your deposits might be greatly affected I'm not going to discuss any banking issues here as they are off-topic in this Mozilla newsgroup. This problem is strictly a software interoperability issue between a server and a client. In order for a web browser, Mozilla, to talk to a web server, some buggy version of IIS 4.0, they must talk the same language, HTTP, an open standard, that is independent of any piece of software or operating system. Let me remind you that if it wasn't for HTTP, there would be no world-wide-web as we know it. I don't think it is acceptable to use software that bastardizes these standards in such a radical way as to completely fail, as it can only contribute to the destruction of the Internet. If you start to make compromises in your software with respect to standards on a case-by-case basis, just because somebody else has a non-compliant implementation and you would like to work with it, soon enough you will no longer have a compliant implementation yourself, and where does that leave interoperability if nobody is following the standard in the end ? The only way for the standard and interoperability to exist is to follow the standard as closely as possible, and to enforce it. When a problem such as this one between two applications shows up, the party that isn't compliant with the standard is the one that needs to make the change. Where it can be troublesome if the problem or the standard is not clear enough to make the determination of who is violating the standard, but fortunately that is not the case here. In this case, my stance is that the error wasn't intentional at all, it is just a bug in the server implementation. Having implemented it both on the server and client side, I can attest that HTTP/1.1 is a significantly more complex protocol than the older versions of HTTP to get right. What the owner of the server needs to do is simply upgrade its server software to fix the problem. The fact that they are running a 4-year old version of a Microsoft web server that's not even HTTP compliant probably means it's not been updated in ages, and that it is vulnerable to countless security attacks that have been discovered in Microsoft web servers, an unrelated but nonetheless serious problem. If I were a user of that server, I would inform its owner of the problems, and I'm sure they would take them seriously. In fact, I have done so in the past with several sites I use, including the bank I use online, when other issues came up, which were standard- and security-related. The sites always ended up correcting the problems, just as is in their interest to do so. -- "Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too." Linux-Kernel archive
