PlayFramework 2.2.6: Advanced HTTP server configuration maxInitialLineLength - rest

We are trying to send GET and POST requests with a length greater than 4096 bytes to our REST API implemented with Playframework 2.2.6.
After a long google research we tried nearly everything and the solution seems to be passing the following two arguments when starting our server via play. We receive no error message about wrong parameters but when we send a large request to the api we still receive the error
TooLongFrameException: An HTTP line is larger than 4096 Bytes
We are running the server by the following command
<PathToPlay>\play-2.2.6\play.bat -org.jboss.netty.maxHeaderSize:102400 -org.jboss.netty.maxInitialLineLength:102400 run

First of all your path to start your application seems off. When you create a new play application a play.bat or activator.bat file is automatically created in your project root folder. So no need to call a specific play installation runtime outside your project folder.
The parameters for setting the max body and header length can be found in the play documentation.
http.netty.maxInitialLineLength
- The maximum length for the initial line of an HTTP request, defaults to 4096
http.netty.maxHeaderSize
- The maximum size for the entire HTTP header, defaults to 8192
Development Mode
To start your application in development mode call
/path/to/project/play run -Dhttp.netty.maxInitialLineLength=102400 -Dhttp.netty.maxHeaderSize=102400
If you've used Activator to create your project replace play with activator.
Production mode
After you've published your application for production with play dist you can set the parameters by calling
/path/to/publishedApp/bin/<nameOfApp> -Dhttp.netty.maxInitialLineLength=102400 -Dhttp.netty.maxHeaderSize=102400

Related

How do I resolve RESTEASY002186 so my Wildfly 26 web application can use SSE over https?

I have a web application running on Wildfly 26 that uses SSE broadcasting and works correctly with http. However, when I switch to using an https endpoint, I get Wildfly log entries of:
WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1)
RESTEASY002186: Failed to set servlet request into asynchronous mode,
server sent events may not work
This happens with each registration attempt of the https endpoint but I never see this when registering with the http endpoint.
Testing with curl against the http endpoint results in curl waiting for events to show up (and keeps printing them out as it receives them) until I quit. Using curl to test the https endpoint, I will see the same headers I got from the http endpoint, namely:
HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: text/event-stream
But after printing out my registration successful event, curl seems to believe the stream is closed and exits -- giving me my command prompt back.
My #GET MediaType.SERVER_SENT_EVENTS registration endpoint will create an OutboundSseEvent and send it to the SseEventSink to acknowledge successful registration to my SseBroadcaster instance (this is the event curl sees and prints before exiting). I then log a registration successful message before exiting the method. All of this appears to work correctly for both http and https but the stream doesn't stay open once the request endpoint completes because of the failure to run asynchronously as outlined above.
I have not found information on the causes and/or workaround solutions for my RESTEASY002186 problem. I posted a question on this issue last week using the Wildfly Google Group (https://groups.google.com/g/wildfly/c/SO2eHdvMEko) but thought I would try a wider audience since this doesn't seem to be a commonly experienced condition. I don't see any indications during initialization that WildFly will be unable to use asynchronous mode, it just complains when it tries and fails... Any help would be greatly appreciated!
Edit 6/6/2022
The code is running on an isolated network so I can't just cut/paste the code here, but I gutted the resources file to a bare minimum -- just leaving enough for the client to be able to register. The problem remains unchanged. The code is now essentially:
#Path("sse")
public class SseResources {
#GET
#Produces(MediaType.SERVER_SENT_EVENTS)
public void listen(#Context Sse sse, #Context SseEventSink sseEventSink) {
SseRegComplete regComplete = new SseRegComplete("sse-server");
OutboundSseEvent event = sse.newEventBuilder().
name(regComplete.getType().toString()).
id(regComplete.getEventId()).
mediaType(MediaType.APPLICATION_JSON_TYPE).
data(SseRegComplete.class, regComplete).
comment("Event Stream Registration Completed Successfully").
build();
sseEventSink.send(event);
}
}
Before the above simplified code, I had declared the resource as #ApplicationScoped, had Sse injected into it, and kept a reference to the SseBroadcaster so I could use it whenever an event would come in. I was catching the events to broadcast by using an #Observes method (which I also got rid of). I was calling register(sseEventSink) on the SseBroadcaster in the listen method so I could later call broadcast(outboundEvent) whenever I had updates to publish. I got rid of all that just to see if I could get the stream to stay open but to no avail. I still get the RESTEASY002186 message and curl still exits after printing out the regComplete event sent to it in the code above.
Edit 6/7/2022
Yesterday I was able to get my code working in a new vanilla Wildfly 26 install using an https endpoint URL by following these configuration instructions. Something I hadn't mentioned in the original post is that I am trying to add SSE functionality to an already existing app. It is several years old and we actually moved to Wildfly 26 about 6 months ago because of the log4j vulnerability in the earlier version of Wildfly we were using. I suspect that the problem is related to either our Wildfly configuration (perhaps because old settings were brought over that shouldn't have been) or some 3rd party dependency that is preventing Wildfly from using asynchronous mode.
We are using Shiro for authentication and authorization against an LDAP server -- perhaps Shiro has some hooks into the Wildfly runtime that are causing issues? After initial login, we use a session cookie in all subsequent calls. That is a difference from my test server but I don't think it is relevant because the call definitely passed authentication before executing the registration code. The only other thing that comes to mind right now is our web app ships with LogBack and tells Wildfly not to use the default logging framework.
I plan to start today by comparing the two standalone.xml files to see if anything jumps out at me as being fundamentally different. Is there anything else I should be checking for differences (I think there is a domain.xml file somewhere...)?
Edit 6/14/2022
This definitely has something to do with Shiro being in the loop. When I edit the web.xml file to have Shiro's filter-mapping url-pattern to not include the SSE endpoint, everything works as expected.

SOAP/HTTP using different folder mappings in ColdFusion

I'm experiencing some strange behaviour with a ColdFusion 11 server, which (among other things) publishes some web services accessed via both SOAP and HTTP. The server itself is Windows 2012, running IIS. Actual folder config is as follows:
IIS has two websites configured, 'BOB' and 'BOB_Services'. Both have been configured with the CF Server Config tool so that CF handles .cfc, .cfm files. They share a common CFIDE config.
BOB's root is I:/inetpub/BOB
BOB_Services's root is I:/inetpub/BOB_Services
There is a folder mapping configured in CF Admin from '/' to 'I:/inetpub/BOB'. Don't ask me why, no one seems to know.
Normally there is a services.cfc file in BOB_Services ONLY. Yesterday we accidentally copied that same file into the BOB root folder, and all of our SOAP services using BOB_Services\services.cfc started throwing errors. Yet I can query the same webservice via HTTP (eg. using http://bob/services.cfc?method=function1&param1=0 ....etc) and get a valid result.
This is a reference answer in case anyone else comes across this strange behaviour.
It appears that when BOB_Services/services.cfc is called using HTTP GET, the folder mapping
'/' -> 'I:/inetpub/BOB'
is ignored and the actual file used to process the request is I:/inetpub/BOB_Services/services.cfc.
When a function in BOB_Services/services.cfc is called using a SOAP client, the folder mapping is invoked and the file used to process the request is I:/inetpub/BOB/services.cfc, IF IT EXISTS. If it does not exist, the file I:/inetpub/BOB_Services/services.cfc is used as expected.
This behaviour appears to be entirely repeatable - I can make a SOAP request, get one result, change the mapping, make another request and get the other result.

Bluemix SAML and timeout session issue

I've created Web Application running on Java Liberty Runtime on Bluemix. Login is done by using SSO service with SAML enterprise provider. After login user redirected to my app and on every JAX-RS request I get user's credentials by following code:
Subject s = WSSubject.getCallerSubject();
Object credential = s.getPrivateCredentials().iterator().next();
String loginToken = credential.toString();
Everything works fine, but if the user has been idle for more then 10 minutes and then perform any ajax request WSSubject.getCallerSubject() returns null, and I required to refresh application.
I've tried to increase timeout by adding following attribute to web.xml:
<session-config>
<session-timeout>60</session-timeout>
</session-config>
But it didn't help. So I'm looking how can I increase timeout or possible I can retrieve user credentials in a different way?
You need to add the optional element <authCache> to the server.xml file to change the default values for the authentication cache.
As you mentioned in your question, the default value is 10 minutes. To change it to 60 minutes you need to include the following in the server.xml file:
<authCache initialSize="50" maxSize="25000" timeout="60m"/>
The documentation here provides more details and also explains initialSize and maxSize options, I left the default value for these two above and just updated timeout.
If you are deploying your application using the default method of pushing the war file, you will need to use a different approach to deploy the application with a custom server.xml file. Please check the documentation here for options on pushing Liberty profile applications (more specific check sections Server Directory and Packaged Server).
In this case, you may also want to check the server.xml file that is currently deployed and modify that version to add the <authCache> element.
You can get a copy of the file by running the following command:
$ cf files <your_app_name> app/wlp/usr/servers/defaultServer/server.xml

Cant access to FTP using Eclipse

I am using the Remote System software on Eclipse. I can successfully log in to my FTP account but when I try to view the directories, I get the following message:
Message: Operation failed due to network I/O error
'java.net.SocketException: Connection reset by peer: socket write
error'
Any ideas are welcome.
Looks like there could be some negotiation issue.
Try following solution:
I've got the same exception and in my case the problem was in a
renegotiation procecess. In fact my client closed a connection when
the server tried to change a cipher suite. After digging it appears
that in the jdk 1.6 update 22 renegotiation process is disabled by
default. If your security constraints can effort this, try to enable
the unsecure renegotiation by setting the
sun.security.ssl.allowUnsafeRenegotiation system property to true.
http://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html
Setting the System Properties/Mode Configuration The various modes are
set using the corresponding system properties, which must be set
before the SunJSSE library is initialized. There are several ways to
set these properties:
From the command line:
% java -Dsun.security.ssl.allowUnsafeRenegotiation=true Main Within
the application:
java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation",
true); In the Java Deployment environment (Plug-In/Web Start), there
are several ways to set the system properties. (See Java Web App and
Next Generation Web Browser Plugin for more information.)
Use the Java Control Panel to set the Runtime Environment Property on
a local/per-VM basis. This creates a local deployment.properties file.
Deployers can also distribute a enterprise-wide deployment.properties
file by using the deployment.config mechanism. (See Deployment
Configuration File and Properties.)
To set a property for a specific applet, use the HTML subtag
"java_arguments" within the tag. (See Java Arguments.)
To set the property in a specific Java Web Start application or applet
using the new Plugin2 (6u10+), use the JNLP "property" sub-element of
the "resources" element. (See Resources Element.)

Stop framework from using HTTP Proxy

After nearly drowning in tears of frustration I have to ask you a question.
My play (2.0.3, scala) application is consuming a wsdl, which works perfectly fine, if I run the dev version of my webservice on localhost, which makes the wsdl-url something like http://localhost:8080/Service/Service?wsdl.
When I try to consume the WSDl from the remote test system server, with an Url like http://testserver.company.net:8084/Service/Service?wsdl, I get:
[WebServiceException: Failed to access the WSDL at: http://testserver.company.net:8084/Service/Service?wsdl. It failed with: Got Server returned HTTP response code: 502 for URL: http://testserver.company.net:8084/Service/Service?wsdl while opening stream from http://testserver.company.net:8084/Service/Service?wsdl.]
My company uses a http proxy for internet use, which is the reason for the 502 error. So I want play to stop using the proxy.
So far I have tried (all together):
deleted proxy from Intenet Explorer
set _JAVA_OPTIONS=-Dhttp.noProxyHosts="testserver.company.net"
set JAVA_OPTIONS=-Dhttp.noProxyHosts="testserver.company.net"
play run -Dhttp.noProxyHosts="testserver.company.net"
None of this worked. Any ideas? How can I stop play from using the HttpProxy?
EDIT:
I found it has someting to do with java Webservices-api / jaxws libraries.
Any ideas?
EDIT 2012-10-17:
It seams to depend on system proxy settings. I still don't know why it didn't work that day although I deleted the whole proxy from IE and restarted everything. Is there any way to make my play app independend from system settings?
Try:
play -Dhttp.noProxyHosts="testserver.company.net" run
I noticed a typo in your property, the correct property is http.nonProxyHosts so add and extra n after no.