I'm upgrading from Tomcat8 to Tomcat9 and sendError does not pass the custom error message that I want to share with the consumer.
I read that sendError and org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER property is deprecated since Tomcat 8.5 but it seems like it works in Tomcat9 for some people.
Once this said then my main question is ... what is then the best way for a permanent solution on sending error messages when responding with error status code?
If the answer is that sendError is still compatible with Tomcat9 then my question is where this org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER should be configured? in which file? and in case it does not exists which is the code I need to add to the file to make it work? Because I found no entry in any of the files in my config directory for this property.
Thanks in advance
PS: I know that there are many posts for this topic but I'm afraid they are some old and/or some are based in Spring and this is not my case.
Amusingly sad question. As far as I can see, Tomcat developers feel that:
"because HTTP/2 doesn't support Reason",
"Reason is optional in HTTP/1.x and primarily intended for human use", and
"smart developer knows HTTP status codes already & doesn't need explanatory text"
They can just delete support for it.
From my perspective of protocol compatibility & systems integration, I think this is just astoundingly wrong. My perspective would be, that so long as HTTP/1.x is supported, all features of HTTP/1.x (whether a client "should rely" on these or not) should be supported.
My belief would be that it should be the overall system owner/ architect's decision -- encompassing the client & server applications, as well as Tomcat -- who makes the decision that they do or don't need Reason Codes.
Tomcat developers are not responsible for these overall systems and, from my perspective, should not be making decisions to delete commonly-expected features of protocols they claim to support which break what they are not responsible for.
However, that seems to be their decision.
http://literatejava.com/web/http-status-reason-broken-in-tomcat-9/
Related
Gwt Documentation http://www.gwtproject.org/doc/latest/DevGuideSecurityRpcXsrf.html
as well as GWT IN action
https://manning-content.s3.amazonaws.com/download/d/07888ea-bada-44cc-9c55-ead15ea7fe85/GWT_sample-07.pdf
recommend extending XsrfProtectedService on client side and XsrfProtectedServiceServlet on server side....
But both thse methods are still marked as
"EXPERIMENTAL and subject to change. Do not use this in production code. "
What gives? is this a leftover - or are they now safe to use in production?
Thanks for your help in advance!
The file has not changed in 7 years. Google is very conservative in their code, and will put scary warnings or mark things as beta when they are, in fact, production ready.
That said, in all matters of security, you should likely submit your code to professionals for security review. This example is using a predictable hash of JSESSIONID, so you need to ensure your JSESSIONID is configured correctly. It must have a domain (and should have a path) so it is only readable on your domain, on URLs deemed safe (once again, professional review is good). If this cookie can be leaked, it becomes trivial for an attacker to exploit.
Just wanted to know if it is possible to know from server that a webserver like Jboss is being accessd by a human being or by a automated tool from a remote system.
This is a huge question that many people have been trying to solve for years, and the problem is not specific to JBoss.
If the automated tool is "good intentioned" it would usually provide a distinctive "User-Agent" header in its requests, by which one easily knows "who's asking". But if the automated tool is trying to pretend to be a human, things can get complicated. That's why CAPTCHA was invented, for example (see a discussion here).
Usually this type of question is considered "not constructive" here, so you'd need to be more specific about your situation.
Please also note that JBoss is more of an "application server" than "webserver".
Does anyone have any insight into what, if any, provisions the WebDAV protocol makes available for version control?
In my never-ending pursuit of a good way to integrate designer tools like SharePoint Designer or Expression with a real source control (which must support live preview), I'm about resigned to the idea that I'll have to write a FPSE server (not hard, but the protocol might not be supported in future revs of the MS tools) that knows how to translate the check-in/check-out RPCs to SVN or TFS.
(I can't install IIS on the designer's machines, Cassini doesn't support classic ASP, and we need live save/preview. Apparently this is the perfect trifecta of stuff that doesn't work together).
WebDAV seems to have a potentially longer lifespan than FPSE, but I can't find a lot of information on any protocol support for check-in/check-out, only folder and file locks. Atomic commits would be nice, but I may be barking up a beanstalk with no climbing gear.
It's all in RFC 3253.
Is there a way I can make a request to a different server than the one that's being used for development using a RequestBuilder?
I keep getting
com.google.gwt.http.client.RequestPermissionException: The URL
http://127.0.0.1:4321/getSellers is invalid or violates the same-origin
security restriction
while I am sending request from 127.0.0.1:8888
GWT currently doesnt support cross domain ajax calls - but it can be worked around if you are willing to do a bit of jsni. And I heard a rumour some time ago that there is a gwt patch with the solution, but its not perfect. see this http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/94c18c4ec158070c/
to work around using jsni, you can use whats called the windows.name transport - see this blog http://www.sitepen.com/blog/2008/07/22/windowname-transport/ . i havent been able to locate a library for gwt to automate this, but i dont think its too hard to do yourself in jsni (and dont me misled by the blog being about dojo, its a general technique).
There is a detailed explanation on the topic of the Same Origin Policy and its consequences for developing with GWT here:
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/FAQ_SOP
The simple answer is: No, that's something that is disallowed for security reasons.
However, it should be possible to work around this limitation with all kinds of techniques (proxy servers, Yahoo Pipes, etc). As I'm no AJAX expert, I will leave the explanation of those to others.
Taken aback to day when I was confronted about the use of validation code used from the Csla framework. It felt like I was reprimanded for not disclosing the use of the framework to the client.
Is this not the same as using libraries such as jQuery etc?
You absolutely should acknowledge what you're using, IMO.
Some clients may have particularly strict legal requirements (whether for legitimate reasons or not - they're the client, it's not up to you to judge their laywers) and detailing any third party software you're using to create a product for them seems only reasonable.
What reason could you have for not wanting to be open with your client?
This depends on the license of the open source code you are using. Many of them require to acknowledge the use in some credits section, others require you to redistribute the source code, etc. You should read the license and act accordingly.
It depends on the project and the kind of client and whatever contracts you had. However, for a typical consultant delivering code to a customer, I would say no it is very strange that you would be reprimanded for not bothering them with details such as the use of CSLA. That's pretty odd.
It is the same, I have a feeling that you would have been reprimanded for using jQuery as well. There are enterprises that frown upon the use of open source for various reasons.
They boil down to
The type of license and what does it force the user to do
The availability of support in some commercial form
The need to 'share-alike' the results
You should know what's your customer/employer's stance on this. If they don't have a stance, then you have to discuss on a case-by-case basis.
I usually tell people I use a lot of open source and, by seeing the response I get I know the path to follow. If they jump and scream at the mention of open source and the lack of support and whatnot, I just tend to ask for budget to buy commercial components or present good cases as to why the open source version of X is better than the commercial alternatives.
It very much depends on the type of project and the type of client. The real problem here is that you were surprised, which indicates non-alignment of expectations. How did the client motivate its interest in Csla specifically?
If your client needs to know or cares about which technology you use, then you should specify everything as part of the project documentation. If the choices are clearly described, then it is easier to have a discussion about them, if required. Documentation also gives you a way to ask (literally) for 'sign-off', if that is the way you work.
From your question it is not clear whether the problem was the choice of framework, or not having informed the customer.
Even on projects with minimal documentation, if the customer owns the code then I always deliver at least a High-level architecture document that includes the names and exact versions of every software component used, along with a brief description of what it is for and why it was selected. This is also the correct place to address any license issues.