> -----Original Message----- > From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] > > "Karr, David" <[EMAIL PROTECTED]> writes: > > > When testing of posting to web services, if the service > returns a SOAP > > fault, it will set the response code to 500. However, the > information > > in the SOAP fault is still useful. When wget gets a 500 response > > code, it doesn't try to output the "error stream" (as > opposed to the > > "input stream"), where this information would be provided. > It might > > be useful to add a command-line option that specifies to emit the > > error stream on error. > > I'm not quite sure what you mean by "error stream" here. The > thing is, web errors are usually in HTML, which is next to > useless if dumped on stdout by Wget. But perhaps Wget should > show that output anyway when -S is used?
When I speak of the "error stream" as opposed to the "input stream", I refer to the terms used in the Java API. The latter is meaningful when the response code is 2xx, and the error stream is meaningful when the response code is not in that range. When HTTP applications are HTML-based, both the input stream and the error stream are likely to be HTML, so it doesn't make sense to exclude one, but not the other. However, when the HTTP application is XML-based, the error stream will often be meaningful (and interpretable). I don't know whether it's reasonable to make the error stream show up by default, or turned on by an option. It depends a bit on whether changing that functionality would affect any existing uses.
