I am using Jetty 7.6 with Scalatra web framework. In some of the requests, I need to send a large text as response body to the client, I use HttpServletResponse.getWriter() to write response.
I noticed that on client side I receive 413 Header Full error. Apparently one solution to this problem in Jetty is to increase jetty's header-buffer-size value.
I would like to know what does HttpServletResponse.getWriter() has to do with the size of the header of request ?! As I understand HttpServletResponse.getWriter() writes into response body rather than response header.
I appreciate if someone could explain this issue.
Unfortunately, this is not only headers that matters (like joakime thougth).
Jetty has a buffer for headers and a buffer for request.
If the full request (http data stream) fits in the hearder's buffer no problem.
If it exceeds the header's buffer, the request buffer will be user.
If it exceeds the request buffer then you got a standard Http response with status 413.
There is the same thing (buffer) for the answer but hopefully Http is designed to send "chunked" response.
I'm facing the same problem with an upload.
What I've found is that you can set the size of those buffers.
See:
http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/server/nio/SelectChannelConnector.html
http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/server/nio/AbstractNIOConnector.html
http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/server/AbstractConnector.html#setRequestHeaderSize(int)
You can use jetty.xml file to do it :
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.server.nio.SelectChannelConnector">
<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>
<Set name="requestHeaderSize">8192</Set>
</New>
</Arg>
</Call>
</Configure>
HTTP response code 413 is HttpStatus.REQUEST_ENTITY_TOO_LARGE.
It has nothing to do with your HttpServletResponse.getWriter().
Capture and check the request headers, you are sending a unreasonable amount of headers to the server.
If you're using or upgraded to Jetty 9, they've removed the SelectChannelConnector. Here is the updated jetty.xml -
<New id="httpConfig" class="org.eclipse.jetty.server.HttpConfiguration">
<Set name="requestHeaderSize">8192</Set>
</New>
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.server.ServerConnector">
<Arg name="server"><Ref id="Server" /></Arg>
<Arg name="factories">
<Array type="org.eclipse.jetty.server.ConnectionFactory">
<Item>
<New class="org.eclipse.jetty.server.HttpConnectionFactory">
<Arg name="config"><Ref id="httpConfig" /></Arg>
</New>
</Item>
</Array>
</Arg>
<Set name="port">8080</Set>
</New>
</Arg>
</Call>
See http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html
Related
I got error:
System.ArgumentException: „The provided URI scheme 'http' is invalid; expected 'https'.
Parameter name: via”
My xml code look like this:
<system.serviceModel>
<bindings>
<customBinding>
<binding name="serviceSoapBinding">
<security allowInsecureTransport="true" enableUnsecuredResponse="true" includeTimestamp="false"
authenticationMode='CertificateOverTransport'
defaultAlgorithmSuite="Basic256"
requireDerivedKeys="true"
messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10">
</security>
<textMessageEncoding messageVersion="Soap11"></textMessageEncoding>
<httpsTransport maxReceivedMessageSize="2000000000"/>
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="http://...Service"
binding="customBinding" bindingConfiguration="serviceSoapBinding"
contract="service.service" name="servicePort" >
</endpoint>
</client>
</system.serviceModel>
Changing http to https is not a solution, because I need http. I think I must change authenticationMode*, but I don't know which mode is right in my situation.
In my case client is authenticated by X509Certificate and service uses http protocol.
DavidG appears to be correct about the CertificateOverTransport requirements.
https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.configuration.authenticationmode?view=netframework-4.8
CertificateOverTransport 2 Specifies that the initiator is authenticated by an X.509 version 3 certificate, and that the responder is authenticated by SSL over HTTPS.
One of the others might work better, but as has been mentioned, not using https is considered highly irregular now.
That said, one of these would likely be your best bet.
MutualCertificate 9
Specifies that the initiator and responder are authenticated with X.509 version 3 certificates.
MutualCertificateDuplex 10
Specifies that the initiator and responder are authenticated with X.509 version 3 certificates.
MutualSslNegotiated 11
Specifies that the initiator and responder mutually authenticate each other using X509 version 3 certificates, and the responder's certificate is available from the SOAP SSL negotiation.
I'm china developer, i use tsung to test my application.
but now , i have problem,
this is my xml code.
<options>
<option name="file_server" id="usernames" value="/usr/local/tsung/username.csv" />
</options>
<sessions>
<session name='rec20160406-1853' probability='100' type='ts_http'>
<setdynvars sourcetype="file" fileid="usernames" delimiter=";">
<var name="user_name"/>
</setdynvars>
<request subst="true">
<http url='http://10.2.0.96:3000/sessions?username=%%_user_name%%'>
</http>
</request>
</session>
</sessions>
username.csv
四方茉莉-Ra
宁靜致遠
阿莫西林
脸骑士
大嗨朵
右眼淤青
程子
这明显不科学
冰与火奏鸣曲
I want send user_name to my application, the user_name is read from csv file, the csv file is chinese content.
I start tsung, and watch the nginx access-log.
log:
192.168.60.61 - - [21/Apr/2016:17:17:29 +0800] "GET /sessions?username=\xE5\x86\xB0\xE4\xB8\x8E\xE7\x81\xAB\xE5\xA5\x8F\xE9\xB8\xA3\xE6\x9B\xB2 HTTP/1.1" 500 70 "-" "tsung"
the user_name encode to be \xE5\x86\xB0\xE4\xB8\x8E\xE7\x81\xAB\xE5\xA5\x8F\xE9\xB8\xA3\xE6\x9B\xB2, my application can not resolve this.
please help me , how can i to do.
I tried to do the tutorials suggested on the MuleSoft's website.
I first started with this example:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.6.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd">
<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8084" doc:name="HTTP Listener Configuration"/>
<flow name="basic_tutorialFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
<expression-filter expression="#[payload != '/favicon.ico']" doc:name="Expression"/>
<logger level="INFO" doc:name="Logger" message="Current payload is #[payload]"/>
<set-payload doc:name="Set Payload" value="#['Hello, ' + message.inboundProperties.'http.request.path' + '. Today is ' + server.dateTime.format('dd/MM/yy') + '.' ]"/>
</flow>
</mule>
Which can be found here http://www.mulesoft.org/documentation/display/current/Basic+Studio+Tutorial
I made it using the drag and drop feature and after that I copied the code on the website just to be sure it wasn't my mistake.
When I enter the URL with no payload it works well. I get this response
Hello, /. Today is 23/01/15.
But when I add a payload like in the tutorial it doesn't work :
Resource not found.
I have tried other examples as well, as long as I don't enter a payload it works. Here is what the console tells me :
INFO 2015-01-23 10:33:55,614 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.api.processor.LoggerMessageProcessor: Current payload is {NullPayload}
INFO 2015-01-23 10:34:32,794 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: No listener found for request: (GET)/asd
INFO 2015-01-23 10:34:32,796 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: Available listeners are: [(*)/]
INFO 2015-01-23 10:34:36,205 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: No listener found for request: (GET)/world
INFO 2015-01-23 10:34:36,205 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: Available listeners are: [(*)/]
So basically the problem is :
INFO 2015-01-23 10:34:36,205 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: No listener found for request: (GET)/world
So with 3.6, the HTTP connector has changed drastically. Here are some changes:
Previously, the HTTP connector would place the contents of the path inside your payload. Moreover, now you need to invoke paths as is. What I mean is that nowadays, if your endpoint is listening on http://localhost:8084/, that's where you need to send the request. Sending a request on http://localhost:8084/HelloWorld will NOT match.
Sending a GET request now will set your payload to NullPayload, which admittedly makes sense, since an HTTP GET does not have an HTTP body.
What I suggest is the following: have your endpoint listening on a path as follows:
<http:listener config-ref="HTTP_Listener_Configuration" path="/{name}" doc:name="HTTP"/>
Notice that I've added a placeholder variable called "name", you can change this to whatever you like. You can then access this placeholder as follows:
#[message.inboundProperties['http.uri.params']['name']]
You can use this expression to return some fancy string, as you're doing above:
<flow name="basic_tutorialFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/{name}" doc:name="HTTP"/>
<set-variable variableName="name" value="#[message.inboundProperties['http.uri.params']['name']]" />
<set-payload doc:name="Set Payload" value="#['Hello, ' + flowVars['name'] + '. Today is ' + server.dateTime.format('dd/MM/yy') + '.' ]"/>
</flow>
Cheers,
JS
As told before, the HTTP Connector is deeply changed from version 3.6 onward.
Now, the connector only listen to the specific path you explicitly define.
My issue was that I wasn't even able to get the WSDL by the obious http://localhost:8080/soap?wsdl.
So, the easiest solution I found to solve this issue was to allow the connector to accept all subpaths by ending the path with the wildcard '*'.
Change your project.xml as I show here:
<http:listener config-ref="HTTP_Listener_Configuration" path="/*" doc:name="HTTP"/>
and all subpaths will be processed.
Here is my tsung.xml:
<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/local/share/tsung/tsung-1.0.dtd">
<tsung loglevel="warning" version="1.0">
<clients>
<client host="localhost" use_controller_vm="true" maxusers="30000"/>
</clients>
<servers>
<server host="127.0.0.1" port="9988" type="tcp"/>
</servers>
<!--
<monitoring>
<monitor host="localhost" type="erlang"></monitor>
</monitoring>
-->
<load duration="90" unit="second">
<arrivalphase phase="1" duration="1" unit="minute">
<users arrivalrate="300" unit="second" />
</arrivalphase>
</load>
<options>
<option name="thinktime" value="0" random="false" override="true"/>
<option name="tcp_snd_buffer" value="4096"/>
<option name="tcp_rcv_buffer" value="4096"/>
<option name="ports_range" min="1025" max="65535"/>
</options>
<sessions>
<session name="mysocket" probability="100" type="ts_raw">
<request>
<raw datasize="1" ack="local"></raw>
</request>
</session>
</sessions>
</tsung>
It tests my socket program, but I cannot fully understand the Tsung report.
Please help to look at this pic, what does "simultaneous" mean?
If anyone can help to tell me something about the report stats, that will be fine.
Stats like following(fetched from Tsung's manual):
users: Number of simultaneous users.
connected: Number of simultaneous connected users. new in 1.2.2.
Is it good or bad if users and connected is low?
Thank you in advance.
The http server will close the TCP socket if there is no action on it for a while or if it is overloaded. The opening and closing of TCP Sockets is handled automatically by Tsung. That said the 'connected' value is the current number 'users' that are connected to the server. Hope this helps
I have a program running on a remote host that I need to connect to, handshake, then listen for messages. I have setup the following camel route:
<route>
<from uri="netty:tcp://localhost:50001?decoders=#decoders&sync=false" />
<bean ref="TransformMessage" method="inboundDecoder" />
<to uri="eventadmin:messages/aacus/inbound" />
</route>
<route>
<from uri="eventadmin:messages/aacus/outbound" />
<bean ref="TransformMessage" method="outboundEncoder" />
<to uri="netty:tcp://192.168.0.111:50001?allowDefaultCodec=false&sync=false" />
</route>
My question is how do I make this work? If I establish the route using
<from uri="netty:tcp://192.168.0.111:50001?decoders=#decoders&sync=false" />
it fails with a binding error.
How can I setup the connection to respond on a specific port without modifying the server?
This is not possible with either camel-mina nor camel-netty at this time of writing. A consumer can only bind to a local server. There is a JIRA ticket at Apache to implement such a new feature for the future. https://issues.apache.org/jira/browse/CAMEL-1077
Use the following workaround:
Instead ob 192.168.0.111 use localhost.
Then install "socat" and start it as follows
socat -s -u tcp4:192.168.0.111:50001 tcp4:localhost:50001
This will Tunnel your remote connection to the local service you created with camel/netty.