> Why? IMHO it should return 400 (Bad request) No. This would be exactly the same inaccuracy as with the 500 errors.
Remember that all *HTTP errors* are in the context of a "dialog" between the server and the client (and they presume that all lower protocol layers have completed successfully). A status code in the 400 series class (400-499) signifies that the client made some sort of error in its request of the server. For examples: the request was malformed, forbidden, unauthorized, or otherwise unacceptable. As with the 500 series errors, the ONLY source of this should be the server which the client is communicating with. It's only that server that will know what constitutes an invalid request. However, as used in HTTPMethod(), that result code is used to signal more errors and results than just HTTP errors. The call could fail due to TCP errors, timeouts, local hardware failure, or other things; and yet the default setting will report a "valid" HTTP error code. (Which also implies at least partially successful communication with the server, since HTTP codes should only come from the server.) As with the 500 errors (and several other error situations I've pointed out), the current structure will return error codes that have absolutely nothing to do with the true error. A simple and prime example is that previous request for help on getting https resources: the user reported 500 errors because that's what the code defaulted to. But it had nothing to do with the with the missing SSL library problem. There is a fundamental mismatch here (exactly as with the LastError property otherwise discussed on this mailing list), in that the code is trying to report multiple *classes* of errors within single variables. This really isn't possible, as Lukas agreed with LastError. The only way to handle this (that we've found) while trying to stay compatible with old code, is to have a special value that alerts the caller to look elsewhere for the true error. I had come up with a possible solution (for compatibility and enhanced accuracy) that I thought was pretty elegant for the LastError problem, but that was months ago, I didn't implement it yet, and I haven't been able to look at it since. I'll try to get to it soon again... Bottom line: all HTTP result codes should come ONLY from whatever server the client is speaking with. That's what they are. If any other errors occur, they need to be recognized and dealt with separately. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
