Jetty HttpParser Full - jetty

I'm getting these warnings in my log file:
WARN 2013-01-15 00:08:15,550 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#2d0a7424{l(/10.13.61.19:17602)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#22e7a7e3,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=2355,c=-3},r=41}
WARN 2013-01-15 00:08:17,275 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#3e428386{l(/10.13.61.19:17605)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#40a77d2a,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-5,l=108,c=-3},r=57}
WARN 2013-01-15 00:09:34,560 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#39c117ad{l(/10.13.61.19:17708)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#11c95f6f,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=1940,c=-3},r=522}
WARN 2013-01-15 00:09:37,185 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#574e9325{l(/10.13.61.19:17722)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#6e997c49,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=2675,c=-3},r=101}
WARN 2013-01-15 00:09:37,281 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#6838d5cb{l(/10.13.61.19:17726)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#d9f6b12,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=2641,c=-3},r=4}
WARN 2013-01-15 00:10:22,723 org.eclipse.jetty.http.HttpParser- HttpParser Full for SCEP#6f282964{l(/10.13.61.19:17805)<->r(/10.118.190.35:80),d=true,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=1r}-{AsyncHttpConnection#44627fa1,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-1,l=2211,c=-3},r=61}
Does anyone know what they mean or how to fix them? I'm using jetty-8.1.5.v20120716 . As you can see, they happen very frequently.

Translation: The request entity is too large.
Some client is issuing an excessively sized request URI + request headers.
This will result in a HTTP Response Code 413 Request Entity Too Large to that client.

Got something similar from maven-jetty-plugin; solved by clearing all cookies for the host.

I met the same question in solr-Query,and the reason is "the request is too long".So I add a set which name "requestHeaderSize" in jetty.xml then the problem is fixed . The size is depended on your demand. Hope this can help you~

I found the root cause of a log message like this (HttpParser Full) to be related to using Kerberos auth.
Kerberos adds header data for each Active Directory group.
See this Microsoft support article for more info.

Related

Intermittent Authentication failed or partial success error

I am getting an intermittent Authentication failed or partial success. (1) error.
ChilkatLog:
AuthenticatePw:
DllDate: May 25 2017
ChilkatVersion: 9.5.0.68
UnlockPrefix: XXXXXXXXX
Architecture: Little Endian; 64-bit
Language: .NET 4.5 / x64
VerboseLogging: 0
login: XXXXXXX
sshAuthenticatePw:
requestUserAuthService:
sendServiceRequest:
svcName: ssh-userauth
SentServiceReq: ssh-userauth
--sendServiceRequest
ssh-userauth service accepted.
--requestUserAuthService
AuthMethods: password
passwordAuth:
Sent login/password
Authentication failed or partial success. (1)
PartialSuccess1: 0
AuthList: password
important:
This is likely a simple invalid login and/or password error,
meaning your application did not send the correct login and/or password.
--important
--passwordAuth
--sshAuthenticatePw
Failed.
--AuthenticatePw
--ChilkatLog
What does the (1) in Authentication failed or partial success. (1) mean? Is it the AuthFailReason mentioned here
The LastErrorText is designed to provide information for quick resolution of problems. It contains the information that would likely be needed by the developer to understand the cause of a problem. In our opinion, it is much better than an obscure single-line message or an error code.
It also provides information for Chilkat -- so that if you send us the LastErrorText, we can see context and usually understand the cause of the problem and the solution in one step. Some lines in the LastErrorText might be obscure to the application developer. That's OK, because they are lines meant for us.
In this case the "Authentication failed or partial success. (1)" line is telling Chilkat the execution path that was taken in the internal code. We don't have to guess.
The SSH authentication protocol is such that it's possible for the server to respond with an SSH2_MSG_USERAUTH_FAILURE response, but indicate partial success. In this case, the partial success was 0 (false), so it points to a hard failure -- most likely the simple case that the username and/or password was incorrect.
There is one more possibility, which is somewhat rare. If the server also accepts keyboard-interactive, then you can set Ssh.UncommonOptions = "KeyboardInteractiveFollowup" (or SFtp.UncommonOptions = "KeyboardInteractiveFollowup") to cause Chilkat to retry with a keyboard-interactive request.

TLS errors using Chilkat library to access Microsoft Graph APIs

I've been trying to use Chilkat library to play around and learn about using Microsoft Graph APIs but it seems I keeps getting TLS errors (connectFailReason 109) with even the simplest GETs and POSTs. This is what a typical log looks like:
ChilkatLog:
QuickGetSb:
DllDate: May 29 2021
ChilkatVersion: 9.5.0.87
UnlockPrefix: XXXXXXXXXXXXXXXX
Architecture: Little Endian; 32-bit
Language: C++ Builder / clang / 32-bit
VerboseLogging: 0
Component successfully unlocked using purchased unlock code.
url: https://graph.microsoft.com/v1.0/users
httpRequestStr:
a_quickReq:
quickHttpRequest:
httpVerb: GET
url: https://graph.microsoft.com/v1.0/users
openHttpConnection:
Opening connection directly to HTTP server.
httpHostname: graph.microsoft.com
httpPort: 443
tls: True
socket2Connect:
connect2:
connectImplicitSsl:
clientHandshake:
clientHandshake2:
ProcessHelloRetryRequest:
readHandshakeMessages:
WindowsError: An existing connection was forcibly closed by the remote host.
WindowsErrorCode: 0x2746
maxToReceive: 5
Failed to receive data on the TCP socket
Failed to read beginning of SSL/TLS record.
b: 0
dbSize: 0
nReadNBytes: 0
idleTimeoutMs: 60000
--readHandshakeMessages
--ProcessHelloRetryRequest
--clientHandshake2
--clientHandshake
Client handshake failed. (3)
--connectImplicitSsl
connectFailReason: 109
ConnectFailReason: 109
--connect2
--socket2Connect
connect: Socket fatal error.
--openHttpConnection
--quickHttpRequest
--a_quickReq
--httpRequestStr
Failed.
--QuickGetSb
--ChilkatLog
The library is not the very latest version but it isn't TOO old (about a year and a half - version 9.5.0.86). I didn't want to upgrade just yet because I have some "live" projects using this dev box (and this is just a "learning journey") so I was wondering if anyone can tell me whether the library version is the most likely issue or whether, perhaps, I'm missing some simple settings in the CkHttp object - the only thing I really do with it is set the auth token (which seems to have been retrieved correctly judging from the logs I output.
The actual API calls are pretty straightforward - mostly simple (slightly modified) examples from Chilkat website. But even the simplest http.quickGetStr("https://graph.microsoft.com/v1.0/me"); fails with a log similar to the above.
So, if anyone can suggest any properties to set to ckHttp to solve this issue (or confirm that library needs to be upgraded to access graph.microsoft.com - if, indeed, that is the case) - I would greatly appreaciate it.
Marko
This problem is already fixed. Contact support#chilkatsoft.com to get a pre-release build for v9.5.0.92.

Twisted ssh - session execCommand implementation

Good day. I apologize for asking for obvious things because I'm writing in PHP and I know Python at the level "I started learning this yesterday". I've already spent a few days on this - but to no avail.
I downloaded twisted example of the SSH server for version 20.3 from here https://docs.twistedmatrix.com/en/twisted-20.3.0/conch/examples/. Line 162 has an execCommand method that I need to implement to make it work. Then I noticed a comment in this method "We don't support command execution sessions". Therefore, the question: Is this comment apply only to the example, or twisted library entirely. Ie, is it possible to implement this method to make the example server will work as I need?
More information. I don't think that this info is required to answer my questions above.
Why do I need it? I'm trying to compile an environment for writing functional (!) tests (there would be no such problems with the unit tests, I guess). Our API uses the SSH client (phpseclib / SSH2) by 30%+ of endpoints. Whatever I do, I had only 3 options of the results depending on how did I implement this method: (result: success, response: "" - empty; result: success, response: "1"; result: failed, response: "Unable to fulfill channel request at… SSH2.php:3853"). Those were for an SSH2 Client. If the error occurs (3rd case), the server shows logs in the terminal:
[SSHServerTransport, 0,127.0.0.1] Got remote error, code 11 reason: ""
[SSHServerTransport, 0,127.0.0.1] connection lost
I just found this works:
def execCommand(self, protocol, cmd):
protocol.write('Some text to return')
protocol.session.conn.sendEOF(protocol.session)
If I don't send EOF the client throws a timeout error.

WSO2 EI log about Java heap space

I have called an endpoint and it response a large data, unfortunately show the error message in WSO2 carbon log . How can I solve it? Thank you.
TID: [-1] [] [2018-02-26 17:48:47,869] ERROR {org.wso2.carbon.das.messageflow.data.publisher.data.MessageFlowObserverStore} - Error occurred while notifying the statistics observer {org.wso2.carbon.das.messageflow.data.publisher.data.MessageFlowObserverStore}
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3236)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
at com.esotericsoftware.kryo.io.Output.flush(Output.java:181)
at com.esotericsoftware.kryo.io.Output.require(Output.java:160)
at com.esotericsoftware.kryo.io.Output.writeString_slow(Output.java:462)
at com.esotericsoftware.kryo.io.Output.writeString(Output.java:363)
at com.esotericsoftware.kryo.serializers.DefaultSerializers$StringSerializer.write(DefaultSerializers.java:191)
at com.esotericsoftware.kryo.serializers.DefaultSerializers$StringSerializer.write(DefaultSerializers.java:184)
at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:628)
at com.esotericsoftware.kryo.serializers.CollectionSerializer.write(CollectionSerializer.java:100)
at com.esotericsoftware.kryo.serializers.CollectionSerializer.write(CollectionSerializer.java:40)
at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:628)
at com.esotericsoftware.kryo.serializers.CollectionSerializer.write(CollectionSerializer.java:100)
at com.esotericsoftware.kryo.serializers.CollectionSerializer.write(CollectionSerializer.java:40)
at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:628)
at com.esotericsoftware.kryo.serializers.MapSerializer.write(MapSerializer.java:113)
at com.esotericsoftware.kryo.serializers.MapSerializer.write(MapSerializer.java:39)
at com.esotericsoftware.kryo.Kryo.writeObject(Kryo.java:534)
at org.wso2.carbon.das.messageflow.data.publisher.publish.StatisticsPublisher.addEventData(StatisticsPublisher.java:116)
at org.wso2.carbon.das.messageflow.data.publisher.publish.StatisticsPublisher.process(StatisticsPublisher.java:67)
at org.wso2.carbon.das.messageflow.data.publisher.observer.DASMediationFlowObserver.updateStatistics(DASMediationFlowObserver.java:55)
at org.wso2.carbon.das.messageflow.data.publisher.data.MessageFlowObserverStore.notifyObservers(MessageFlowObserverStore.java:71)
at org.wso2.carbon.das.messageflow.data.publisher.services.MessageFlowReporterThread.processAndPublishEventList(MessageFlowReporterThread.java:225)
at org.wso2.carbon.das.messageflow.data.publisher.services.MessageFlowReporterThread.run(MessageFlowReporterThread.java:95)
By looking at the out of memory issue it is hard to say anything about the culprit. In order to find out the actual root cause we have to analyze the heapdump (There will heapdump created by wso2 servers automatically in CARBON_HOME/repository/logs/heap-dump.hprof) using an analyzing tool such as MAT, jprofile.
However, if the response message is large, there is a possibility that the server goes OOM as it keeps and may build the response message in memory. If you want to process large messages, you can tune the heap memory allocation as in the doc.

Some questions about protobuf

We are building a RTB(real time bidding) platform. Using nginx as http server, the bidder is writen in lua, google protocol buffer for serializing data and Zlog for logs. After test runs, we got three error messages in the nginx error log:
"[libprotobuf Error, google/protobuf/wire_format.cc:1053]
String field contains invalid UTF-8 data when parsing a protocol buffer.
Use the 'bytes' type if you intend to send raw bytes."
So we went back to check the source code of protocol buffer, and found that this check is controlled by a macro(-DNDEBUG: it means NOT debug mode?, according to the comment). And -DNDEBUG disables GOOGLE_PROTOBUF_UTF8_VALIDATION(i think?). So, we enabled this macro(-DNDEBUG) in the configuration. However, after testing, we still got the same error message. And then, we changed all the "String" type to "Bytes" typr in XXX.proto. After testing, the same error message showed.
worker process 53574 exited on signal 11(core dumped),then process died.
lua entry thread aborted: runtime error:/home/bilin/rtb/src/lua/shared/log.lua:34: 'short' is not callable"
Hope somebody can help us solving those problems.
Thank you.