You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
length or b is not necessarily 1024 as we expect this is due to how net.Conn and network I/O works .
Context
In golang network I/O is Non-Blocking stream based hence it returns as soon as there is some data available . Let's say if server has 500ms difference between two consecutive messages it sends then even if both of them can fit into buffer/ byte array b only 1st one is read . and there are also other factors here i.e
underlying buffers (os)
network congestion / latency
Non Blocking I/O design of golang
i.e why all stdlib implementations of a protocol use for loop to make sure we are reading xyz bytes of data so instead of above example below is preferred or used everywhere
but it was identified recently with Read and Name attributes of network.Input() not working #4454 that there was a timeout for network protocols while reading and the reason was that in template we were trying to read 1024 bytes and only 256 bytes i returned by server and hence the connection timeout out after waiting for timeout [Note: protocols like ftp etc are dynamic length based protocols so we don't know upfront what the size of next response is but such protocols have a delimeter for example ftp has \r\n similar to other protocols] ( in earlier implementation it would just return whatever was available
currently we are resolving/resolved this by reverting to old behaviour and furthur investigation is needed to identify what would be the best behaviour and changes that need to be made
The text was updated successfully, but these errors were encountered:
This is not a bug but optional pattern to implement but is limited to cases where we are 💯 sure that response length will be xyz bytes and we are willing to wait
Nuclei version:
Problem Statement
In golang when we do
length or b is not necessarily 1024 as we expect this is due to how net.Conn and network I/O works .
Context
In golang network I/O is Non-Blocking stream based hence it returns as soon as there is some data available . Let's say if server has 500ms difference between two consecutive messages it sends then even if both of them can fit into buffer/ byte array
b
only 1st one is read . and there are also other factors here i.ei.e why all stdlib implementations of a protocol use for loop to make sure we are reading xyz bytes of data so instead of above example below is preferred or used everywhere
In Nuclei
net.Conn.Read()
(example 1) in network protocols so even when template says 1024 bytes it doesn't necessarily read 1024 bytes . this was a identified in javascript net module and fixed in nuclei v3.0.3 see Incomplete Data Received with Nuclei's JavaScript NetConn ('nuclei/net') #4285\r\n
similar to other protocols] ( in earlier implementation it would just return whatever was availableThe text was updated successfully, but these errors were encountered: