So it all began with WebDAV (or webfolders as MS calls it), that is an HTTP extension. We use Oracle Application server 9.0.4.2.0 (not supported by now, but it is used by our customers, who are banks and it is quite hard to get them to upgrade / install anything)
By most application servers have a built-in webdav servlet, you just have to configure it to start using it. Since we had to customize ours, we've used an implementation found on SourceForge. Our goal was to create a document, make it available through an url to microsoft office via webdav, so if the user pressed save, it would update the document on the server (ok, actually some ajvascript ole automation was involved, too but its not related to the issue closely). Nice, but the documents opened read-only. We weren't sure, if it was an Office or a servlet issue. I've tested several application servers, several Office versions, several servlets. And the results were inconsistent. Sometimes the same setup worked, and after a couple of tries, it stopped (Office not even seeing the webfolder). After installing a few patches, it worked. After a couple of hours it stopped.
So days went by, we made new theories. Some setups seemed to work all the time, so I've called in the artillery, and started to analyze the IP packets with WireShark (fka Ethereal). Some strange things started to materialize: IIS webdav implementation sent quite different answers from what the java based servlets were sending (or they were simply structured in another way, omitting default values, etc.).
Yesterday it was evident, that my implementation of the servlet worked fine on BEA Weblogic servers (the other half of our customers are using it, so it was a small victory) with unpatched Offices(!). So we only had to compare the responses of the Oracle and the BEA servers. Finally while using netcat, I've noticed, that sending the requests as HTTP/1.0 instead of HTTP/1.1 made things work. But how could we get Office to do this? Not easy. This was another byproject, but finally we've found the solution: if we've omitted the body of the request, it worked. Now that was the big wtf moment: the default implementation of the LOCK method of the servlet didn't read the body of the message, and the Oracle application server started to interpret it as a new request, and threw an illegal url exception - that resulted in a Bad request response right after the successful lock response (so it looked like coming out of nowhere, however it closed the communication stream, but Office sent the GET request right after this, thus it looked like that the Oracle server was really an Oracle that knew in advance, what request it is going to receive, and answered it in advance - and since the stream was closed, it didn't answered the real request at all, really funny).
Solution? Easy, just ALWAYS read the body of the request.
Thank you Oracle, it took a week of my life (and building a test network of 3 computers), but I've learnt a lot. And yeah, nothing on google (I've tried to search for it now that I know the solution, and still couldn't find anything relevant)...

So, is this a bug or a feature?
If it is common knowledge, that servlets has to read the body of the http requests, than it's all my fault (but all other application servers that I've tried didn't require it at all)...

This post has been edited by skyhawk133: 20 Jun, 2007 - 05:41 AM

The last 3 version of ColdFusion have had an old version of ODBC drivers. There is a bug in the driver that causes the server to drop the TCP connection. This results in requests hanging and eventually timing out.

It took us MONTHS to track this down even with the support of Macromedia engineers. We were sending 100MB+ java stack traces, log files, and screen shots every day.

Even after we identified the bug, the next 2 versions of CF didn't include the update, but we were invited to participate in the beta for CF8 and this time we got it included.

2 months fighting with a bug is the longest I can remember.

I blogged about dump Perl Net::LDAP and Openldap
http://www.dreamincode.net/forums/blog/nov...p?showentry=396

Euch...doubly encrypting a password, in my case.

When a user signed up for something I was building, I'd store their username and their encrypted password in the database, before writing a cookie with both their username and encrypted password.

Then, to check if a user was logged in, I'd retrieve the two values, encrypt the retrieved password, and compare it to the database. Anyone see the problem here?

I must have ripped out and rewritten the system 4 times over 2 weeks before I figured out what was going wrong. =/

I downloaded a free shopping cart & added an entire shipping section to it.

What it came with was "type in the shipper name: type in the shipper amount". So I could offer $5 for all fed ex deliveries, should it be a floppy drive, a laptop, or a 4U server, it was $5. So I've added XML requests to give shipping weight & totals with UPS, DHL, FedEx, & USPS. It'll do requests from multiple zip-codes (if you use drop shippers, you know why this is important), & I'm still stuck on one little piece of code. I'm simply burnt out on the project right now, it can wait!

Just something similar: in Javascript I was urlencoding a parameter twice (with two different methods naturally), and could not find why everything looked funky on the server side. Well, that's all for mindlessly copy&pasting code found in the tubes of the internet...

Adobe was kind enough to add a new feature to the FLVPlayback (Flash Video) component in AS3. By default, the video takes over the entire screen when the SWF file is viewed in Full Screen mode. It drove me CRAZY trying to figure out what was going on. I finally figured it out today, while trying to solve another video problem. Too much fun!

</rant>