I already know that if you try to set a http header once part of the content is sent, an error should be raised or the header should be ignored. This is part of the common sense.
My question is if java HttpServlet.setHeader() or addHeader throws an exception in that cases or are silently ignored. AFAIK the documentation doesn't show much help.
I've seen errors in a was server reflecting an error like that, but appears to be an error raised than a filter rather than an error of the application itself.
Answer is in Servlet specification:
5.2 Headers
...
To be successfully transmitted back to the client, headers must be set before the
response is committed. Headers set after the response is committed will be ignored
by the servlet container.
...
So, no exception.
Related
Earlier we used to get 401 and based on that we are taking some decisions in our application, but now instead of getting the response, an exception is received with
java.lang.IllegalStateException: AuthScheme is null
at org.apache.hc.core5.util.Asserts.notNull(Asserts.java:56)
at org.apache.hc.client5.http.impl.auth.HttpAuthenticator.updateAuthState(HttpAuthenticator.java:229)
After digging into the library code, I found that authEchange state is set as challenged as below are the header present in the response,
"WWW-Authenticate: WSS-JWT"
"WWW-Authenticate: Negotiate"
"WWW-Authenticate: NTLM"
And it tried the same endpoint again.
Questions:
I didn't find/see a way to set AuthScheme that looks a error to me.
Is there any way to skip the second attempt and get the response 401.
Why this behavior is changed after library update.
I have a web app which sends HTTP status codes. In some instances, a 404 code is sent as a header, but then a 200 error is sent as well, in the same response.
HTTP/1.0 404 Not Found
HTTP/1.0 200 Ok
I can't change the execution order to prevent the first status code from being sent, so the second code is attempting to override it.
Chrome ignores the first code and assumes the status to be Ok. Does this conform to the HTTP standard, and should I rely on it?
No, it does not conform to the standard, and you should not rely on it. See https://www.greenbytes.de/tech/webdav/rfc7230.html#rfc.section.5.6:
More than one response message per request only occurs when one or more informational responses (1xx, see Section 6.2 of [RFC7231]) precede a final answer to the same request.
The rfc for http 1.1 is given here: https://www.rfc-editor.org/rfc/rfc7230
Section 2.1 states:
A server responds to a client's request by sending one or more HTTP
response messages, each beginning with a status line ...
The standard states that you can send more than one response, if you wish, but that each response must have it's own status line. Further, the first line of the header must contain the status-line/code.
So, according to the standard interpreted literally, in theory you can send more than one response, but I've no idea what browsers would do with that, and definitely wouldn't rely on it.
What you've got at the moment is conforming to the rfc; the rfc doesn't say you can't have more than status line, only that the status line on the first line of each response is the one that matters - which chrome doesn't interpret correctly according to the rfc.
It might work, but I wouldn't rely on it.
I am in reference to HttpServletResponse's sendError method:
void sendError(int sc,
java.lang.String msg)
throws java.io.IOException
... and the official documentation provided:
Sends an error response to the client using the specified status and
clears the buffer. The server defaults to creating the response to
look like an HTML-formatted server error page containing the specified
message, setting the content type to "text/html". The server will
preserve cookies and may clear or update any headers needed to serve
the error page as a valid response. If an error-page declaration has
been made for the web application corresponding to the status code
passed in, it will be served back in preference to the suggested msg
parameter and the msg parameter will be ignored.
If the response has
already been committed, this method throws an IllegalStateException.
After using this method, the response should be considered to be
committed and should not be written to.
Can anyone please explain what is meant by "clears the buffer" and "If the response has already been committed"?
what is meant by "clears the buffer"
The code will response.resetBuffer() which basically resets any written and unflushed data of response body.
and "If the response has already been committed"?
If the response headers are already sent to the client. This is a point of no return. The server cannot take back already sent data from the client and re-send a different response.
An example of the normal flow is as below:
user requests JSP
JSP writes some HTML to response body
some awkward code in midst of a JSP file throws an exception
server calls response.sendError(500) so that HTML of HTTP 500 error page will be written
user sees HTTP 500 error page
However, if between step 2 and 3 the response buffer is flushed (i.e. any so far written data gets actually sent from server to client), then the response is in a "committed" state. This cannot be resetted. The enduser basically ends up getting halfbaked HTML output representing the part until the point the exception has occurred.
That's also one of the reasons why doing business logic in a JSP file is a bad practice. See also a.o. How to avoid Java code in JSP files?
I am using webMethods from the SAG and it seems if the service
pub.client.http
throws an exception on status code 401 "Unauthorized".
This leads me to the problem that I cannot handle the status code because nothing is written to the pipeline.
getLastError
does contain the string "Unauthorized" but not the status code.
Except that I do not want to start parsing exception messages...
Any ideas?
The output parameter header from the pub.client.http call should contain the information you’re after:
header Document Conditional. HTTP response headers.
Key Description
lines Document Fields in the response header, where key names represent
field names and values represent field values.
status String HTTP status code of the response.
statusMessage String HTTP status message of the response.
See the webMethods Integration Server Built-In Services Reference page 122 for more details.
Asked a SAG senior consultant.
This is the normal behavior.
There is no flag which you can set to enforce suppression of this exception...
You can suppress the exception and have the HTTP 401 status returned like any other HTTP response. Go to the IS Admin Extended Settings and set:
watt.net.http401.throwException=false
Note this is a server-wide setting, so it will affect all your applications/services that use pub.client:http.
According the comment from #Hugo Ferreira probably there are ACL restriction whether inside your webMethods environment, or your client URLs.
Things you should consider:
Do your webMethods server located inside closed environment wherein need to get connected to proxy to get to the outgoing request. Which is likely you can investigate by run web-browser program directly from your wM server towards the URL address (i.e using SSH to run firefox in my case and popup appeared)
The client that your request will go to, have HTTP for authentication requests
Solution
To pass this all you need to do is input the auth user/password or any other auth mechanism i.e kerberos, token, etc. inside the pub.client:http
What HTTP status should I return if my script throws an exception?
200 OK
or
500 Internal Server Error
Let's say user request parameters are correct but there is a bug in my script which causes an error message to appear instead of a proper response (XML, JSON or other format). What should be the HTTP status?
500 Internal Server Error is the correct status if the error can't be fixed by the client changing their request.
Use any of the 4XX statuses if the client might be able to fix their request to avoid the error (or 404 if the resource wasn't found).
200 OK is not the appropriate status in almost any error situation, because then the client thinks things are running normally (which they are not) and may continue to make the same error-causing requests.
Familiarize yourself with the available status codes in RFC2616 and find one that most appropriately fits the situation.
It depends on why the exception is thrown since they can be used for almost any error. If it's thrown because some id in the URI is not found in the database I'd say 404. On the other hand if it's because the database is down I would throw a 500. If an exception is thrown but the resulting page would still be useful to the user I would say return 200.
Review the Status Code Definitions. 500 or 400 should do for general issues, however, the more detailed you can be then the more useful the returned status will be.