We Keep Coding

Force tomcat to use only HTTP 1.0 or ignore Except header

Is there a possibility to force tomcat to ignore "Expect" header or to use only HTTP 1.0?
I am sending curl request curl POST -vv 'http://127.0.0.1:8080/test' -d "#requests/test.xml" -H "SOAPAction: abc/test" -H "Content-Type: text/xml; charset=UTF-8" and curl adds by default "Expect" header which causes server waits for another request which never come.
Tech stack: Springboot 2.1.3.RELEASE, Tomcat 9.0.16
I cannot modify clients and to their requests empty header "Expect:".

I don't think there is a way to get Tomcat to respond only with an HTTP 1.0 response. That would be a protocol violation. If server gets an HTTP 1.1 request it must either respond with a HTTP 1.1 compatible response, or signal that it can't with a 505 HTTP Version Not Supported error.
Likewise, I don't think there is a way to get Tomcat to ignore a (well-formed / non-empty) Expect header. That would also be a protocol violation.
(While it is possible in theory for a server to violate the spec, I couldn't find a way to configure Tomcat to do that. Obviously you could download the Tomcat source code and modify it, but then you have the problem of maintaining your "fork".)
So what are the alternatives:
The HTTP spec says that server must ignore an Expect header in an HTTP 1.0 request. So you could add the --http1.0 option to the curl command.
The curl command uses a defaults file - ~/.curlrc - to get default overrides for various things. You could add an empty default for the Expect header into this file; see How to setup default "Expect" header for curl.
However, I think you may be worried unduly:
If you are worried that this will slow up the client (curl), don't. By default it only waits for 1 second for the 100 Continue response. (And I don't think that is what you are talking about ...)
If you are worried that this might tie up server side resources (in Tomcat), I can't see how that could be significant. The Tomcat server will timeout and close a client connection if there is no activity. This should deal with a curl command that sends the initial request but doesn't follow up.

Https web service call failure

We have implemented webservice call using JAX-WS RI 2.1.6 in JDK 6 now problem comes when we enable https webservice call stops reaching server and java reports following error,
javax.xml.ws.WebServiceException: java.io.IOException: Async IO
operation failed (3), reason: RC: 55 The specified network resource
or device is no longer available.
Now I have tested this within SoapUI and response from the service is received there.
Looked into various solution where it tells us to provide timeout settings but nothing seems work.
#WebEndpoint(name = "RulesSoap")
public RulesSoap getRulesSoap() {
((BindingProvider)super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class)).getRequestContext().put("com.sun.xml.internal.ws.connect.timeout", 1000);
((BindingProvider)super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class)).getRequestContext().put("com.sun.xml.internal.ws.request.timeout", 1000);
return super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class);
}
And just for information JAX-WS implementation is following few simple lines,
of course we submit all necessary data into respective stubs and all but I am not submitting here because our http calls are getting through,
Rules rules = new Rules(new URL(url), new QName("urn:decision:Rules", "Rules"));
RulesSoap rulesSoap = rules.getRulesSoap();
CorticonResponse response = rulesSoap.processRequest(request);
Note : Our application server WebSphere Application Server and Version 7.0.0.19
Thanks in Advance.

After lots of efforts we resolved this. I will provide steps if anything related to this happens how to find root cause,
Step 1 :
First of all we enabled soap tracing in WebSphere Application Server by following setting,
Admin Console > Servers > Server Types > WebSphere Application Servers >
{your server} > Troubleshooting > Change Log Detail Levels > Runtime
In run time please put this , *=info: com.ibm.ws.websvcs.*=all: org.apache.axis2.jaxws.*=all
This step will create trace.log file in your logs folder.
Now any web service request which goes out of your server will add logs to this file and necessary props like endpoint, request, response etc.
Step 2 :
Reading this trace.log file we found following endpoint,
PropertyValid 1 org.apache.axis2.jaxws.client.PropertyValidator validate validate property=(javax.xml.ws.service.endpoint.address) with value=(http://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0)
HTTPConnectio 3 resetConnection : http://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0 Persistent : true
Now if you notice here that our soap has endpoint address javax.xml.ws.service.endpoint.address where protocol is still using http which causes to fail ssl handshake.
Step 3 :
Solution for this is to override endpoint inside your soap stubs which can be implemented by adding following line,
RulesSoap rulesSoap = rules.getRulesSoap();
((BindingProvider)rulesSoap).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0");
Conclusion :
So here is what i think even we pass https url while we are creating objects but still does not take this https url on runtime, to me this looks like stubs creation issue with JAX-WS.
Thanks.

What protocol /ciphers are you using? You have mentioned there is connection to webservice on WAS7 with JDK6 and Java 6 does not support TLS1.2 (and TLS1.1 only from certain fixpack).
See this:
How to use TLS 1.2 in Java 6

Azure Storage Blob : https://(storageAccountName).blob.core.windows.net/vhd?restype=container&comp=list not working using proxy

For getting the blob container details we are using the below mentioned REST API.
Vhd is the blob container name.
https://(storageAccountName).blob.core.windows.net/vhd?restype=container&comp=list
When we use proxy server details (example:SQUID Proxy) to access the storage REST API calls, we are getting the below mentioned error.
HttpResponse for Blobs:: ResourceNotFoundThe
specified resource does not exist.
RequestId:6dc7e6f2-0001-000d-30f9-d56eb3000xxx
If we access the same rest api without proxy server, we are getting the valid response and it's working.

Per my experience, normally, using squid is as reverse proxy for backend services, but here you want to access the storage REST APIs via squid as forward proxy. You can refer to the wiki page https://en.wikipedia.org/wiki/Proxy_server, the SO thread Difference between proxy server and reverse proxy server and the blog to know the differences between both.
So the solution for the issue is that configuring the proxy server as forward proxy.
For Squid, you can try to refer to the squid wiki pages http://wiki.squid-cache.org/SquidFaq/ConfiguringSquid and http://wiki.squid-cache.org/Features/HTTPS to know how to configure as forword proxy with HTTPS.
For Apache, you can try to refer to the apache doc page http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#forwardreverse to do.
Then, setting the system properties for Java to enable proxy support after setting up forward proxy successfully.
There are two ways support proxy for Java.
Command Line JVM Settings: The proxy settings are given to the JVM via command line arguments:
java -Dhttp.proxyHost=proxyhostURL -Dhttp.proxyPort=proxyPortNumber -Dhttp.proxyUser=someUserName -Dhttp.proxyPassword=somePassword HelloWorldClass
Setting System Properties in Code: Adding the following lines in your Java code so that JVM uses the proxy to make HTTP calls.
System.setProperty("http.proxyPort", "someProxyPort");
System.setProperty("http.proxyUser", "someUserName");
System.setProperty("http.proxyPassword", "somePassword");
System.setProperty("http.proxyHost", "someProxyURL");
More information for Networking & Proxies & Properties in Java, Please refer to http://docs.oracle.com/javase/7/docs/technotes/guides/net/proxies.html and http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html.

we got the solution. The issue is we are invoking asynchronous calls for all storage accounts at a time. For example : if we have 5 storage accounts and each storage accounts 5 vhd containers and in for loop if we invoke all 5 at time and with callback waiting for 5 response,In this case it's not working. so we are invoking each call separately and it's started working.

Dropwizard config (yml) behaves strangely

I'm working with the Dropwizard sample project from the tutorial and faced the following strange issue:
With the following server config
server:
type: default
applicationConnectors:
- type: http
port: 8080
My resource returns the correct response.
When I change it to:
server:
type: simple
I see (from Jetty's logs) that it was correctly registered and loaded but doesn't work - if I try the same path I see 404 in browser and
GET /wizard-resource/rs 200
in the logs. I've tried to find the difference between simple and default in yaml configs but Google didn't shed much light on the topic.
So, here are two questions:
Why with simple connector do I get a 200 in logs but 404 in browser?
What is the use of simple connector and when it is better than default?

According to Dropwizard Javadocs:
Simple Server
A single-connector implementation of {#link ServerFactory}, suitable
for PaaS deployments (e.g., Heroku) where applications are limited to
a single, runtime-defined port. A startup script can override the
port via {#code -Ddw.server.connector.port=$PORT}.
Default Server
The default implementation of {#link ServerFactory}, which allows for
multiple sets of application and admin connectors, all running on
separate ports. Admin connectors use a separate thread pool to keep
the control and data planes separate(ish).
It's also mentioned (though not thoroughly) in the Configuration Reference documentation.
Not sure why it's logged as 200 while it's 404, it could be a bug; but the reason you're getting 404 could be because the default applicationContextPath config in simple server is /application. So if you try
GET /application/wizard-resource/rs
it should work.

Jolokia - Origin null is not allowed to call this agent

{"stacktrace":"java.lang.Exception: Origin null is not allowed to call
this agent\n\tat
org.jolokia.http.HttpRequestHandler.handleThrowable(HttpRequestHandler.java:242)\n\tat
org.jolokia.jvmagent.handler.JolokiaHttpHandler.doHandle(JolokiaHttpHandler.java:243)\n\tat
org.jolokia.jvmagent.handler.JolokiaHttpHandler.handle(JolokiaHttpHandler.java:178)\n\tat
com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)\n\tat
sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)\n\tat
com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:82)\n\tat
sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:675)\n\tat
com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:79)\n\tat
sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:647)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
java.lang.Thread.run(Thread.java:748)\n","error_type":"java.lang.Exception","error":"java.lang.Exception
: Origin null is not allowed to call this agent","status":403}
I get this error when I try to query my "jolokia" agent.
curl http://localhost:8778/jolokia/list
I've launched my java application (kibana) with the jolokia agent, as explained in the Manual https://jolokia.org/reference/html/agents.html#agents-jvm.
java -javaagent:agent.jar=port=8778,host=localhost
I can see (ps -aux) that the process launched with the jolokia agent in between the Java Arguments.
I have also tried to deploy the jolokia war in my Tomcat /webapps. I've edited the user.xml file to add the User Jolokia, but I get the same result
The only result I get by googling the error seems to be the Jolokia code, at line 287, which seems to imply the host or address are wrong, but i'm doing everything from localhost, which should be allowed.
https://github.com/rhuss/jolokia/blob/master/agent/core/src/main/java/org/jolokia/http/HttpRequestHandler.java
Am I missing some settings? which is the best way to test it? I have zero experience with Java applications and Jolokia.

Jolokia default setting is set to block all CORS, in apache-activemq/webapps/api/WEB-INF/classes/jolokia-access.xml file.
<cors>
<strict-checking/>
</cors>
You can disable it by removing above config or adding allowed origins before ** strict-checking**.
<cors>
<!-- Allow cross origin access from www.jolokia.org ... -->
<allow-origin>http://www.jolokia.org</allow-origin>
<!-- ... and all servers from jmx4perl.org with any protocol ->
<allow-origin>*://*.jmx4perl.org</allow-origin>
<!-- Check for the proper origin on the server side, too -->
<strict-checking/>
</cors>
For more details please refer 4.1.5. Cross-Origin Resource Sharing (CORS) restrictions

Depending on your current configuration need to be changed.
Based on your exact error line, you need to add "Origin" header in your http request.
For example - curl http://localhost:8778/jolokia/list -H "Origin:http://localhost"
Remember, if you have default CORS is enabled, add exception with <allow-origin> under <cors> tag.