I'm trying to implement HTTP/1.1 protocol using Socket in C language. I just want to know if the Body inside a request can contain strings like: "\r\n" i.e a CR LF.
Also, please let me know if there is a maximum limit to the number of characters inside the body.
There are no limits to the size or content of the body in an HTTP request or response.
Yes, the body can contain CRLFs. No, there is no limit to the length of the body. The body is arbitrary data, as far as HTTP is concerned. RFC 2616 Section 4.4 outlines how to determine the length of the body and how the body is transmitted. The Content-Type header determines how the body data is interpreted once received.
Related
I am using akka-streams and I hit an exception because of maxing out the Http Pool on akka-http.
There is a Source of list-elements, which get split and thus transformed to SubFlows.
The SubFlows issue http requests. Although I put a buffer on the SubFlow, it seems the buffer takes effect per SubFlow.
Is there a way to have a buffer based on the Source that takes effect on the SubFlows?
My mistake was that I was merging the substreams without taking into consideration the parallelism by using
def mergeSubstreams(): Flow[In, Out, Mat]
From the documentation
This is identical in effect to mergeSubstreamsWithParallelism(Integer.MAX_VALUE).
Thus my workaround was to use
def mergeSubstreamsWithParallelism(parallelism: Int): Flow[In, Out, Mat]
I have a string that was sent over a network and arrived on my server as a Buffer. It has been formatted to my own custom protocol (in theory, haven't implemented yet). I wanted to use the first n bytes for a string that will identify the protocol.
I have done:
data.toString('utf8');
on the whole buffer but that just gives me the whole packet as a string which is not what I want to achieve.
When the message is recieved, how do I convert a subset of the bytes into a string?
Thanks in advance
The Buffer.toString() method accepts start and end parameters, which you can use to slice out just the subset you want for your substring. This may, depending on your implementation, be faster than allocation a new intermediary Buffer like you suggested in your answer.
Check out Node's Buffer.toString() method for more information.
Found out how.
You have to copy the amount of bytes you want into another buffer by calling the method copy on the original buffer i.e:
sourceBuffer.copy(targetBuffer, targetStartIndex, sourceStartIndex, sourceEndIndex)
This will give your targetBuffer the required data which you can then call toString() or any other metod to convert the buffer array into your desired data type.
I know I'm a bit late to this, but why not just something like:
buffer.subarray(0, bytes).toString();
I am using $resource to make a rest api call.
My call to that resource is like that :
Client.get({parametres : param}
My problem is that param contains "\" character, that make the call fail with
400 Bad Request
response.
How can I escape the "\" character?
Thanks.
encodeURIComponent should do the trick.
The encodeURIComponent() method encodes a Uniform Resource Identifier (URI) component by replacing each instance of certain characters by one, two, three, or four escape sequences representing the UTF-8 encoding of the character (will only be four escape sequences for characters composed of two "surrogate" characters).
As per: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent
Client.get({ parameters: encodeURIComponent(param) }
I'm trying to get the size of a chunk of data sent via NetLink (Linux Kernel).
I have tried with size = nlh->nlmsg_len - NLMSG_HDRLEN, but that isn't returning the correct size.
What's the correct way to get the message's data size?
Why would you believe nlh->nlmsg_len - NLMSG_HDRLEN is not returning the {message size without header} for the message you are looking at? If nlmsg_len contains, for example, the value 16 (that's what NLMSG_HDRLEN should be), then the payload of this message is empty. Your buffer may have more messages in it that want to be read.
As a side note, I recommend you use libmnl for Netlink message parsing and construction.
I want to ask a question about the multipart/form data. I find the http header of multipart post and the Content-Type: multipart/form-data; boundary=-----...---boundaryNumber. I want to ask, how many of '-' between the boundaryNumber and '='?
Not a single - is mandatory. You can have any number of them. It is actually a mystery to me why user-agents tend to add so many. It is probably traditional because in the old days, when people still regularly looked at the actual protocol traffic, it provided some nice visual separation. Nowadays it is pointless.
Note however, that when you use the boundary in the stream, it must be prefixed by two hyphens (--). That’s part of the protocol. Of course, the fact that most user-agents use lots of hyphens in their boundary makes this very hard to see by example.
Furthermore, the last boundary (which marks the end of the message) is prefixed and suffixed by two hyphens (--).
So in summary, you could call your boundary OMGWTFPLZDIEKTHX, and then your traffic could look like this:
Content-Type: multipart/form-data; boundary=OMGWTFPLZDIEKTHX
--OMGWTFPLZDIEKTHX
Content-Type: text/plain
First part (plain text).
--OMGWTFPLZDIEKTHX
Content-Type: text/html
<html>Second part (HTML).</html>
--OMGWTFPLZDIEKTHX--
The number of dashes depends on how many you want there. It can be zero, if you like -- it's just that more dashes makes the boundary more obvious.
The boundary consists of a line containing two dashes plus everything after "boundary=". So if your header said boundary=ABC, the boundary looks like
--ABC
In your boundary definition, no hyphens are required. When using that boundary to separate two distinct body parts, you must start with two hyphens, followed by your previously-defined boundary string.
This is explained in RFC 1341 (MIME), and you can find additional information there in the Multipart section (as linked).
It is completely arbitrary.
The point of the boundary is to define the beginning and ending of your data. It does not matter what it is, as long as it is not part of the content.
Multipart/form-data media type can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form.
Multipart/form-data follows the model of multipart MIME data streams. A multipart/form-data body contains a series of parts separated by a boundary.
Example of multipart/form-data response:
There are four important fields which we are important in response:
-<<boundary_value>>
Content-Disposition: form-data; name="<<field_name>>"
Content-Type: type of the data
<<field_value>>
The "Boundary" Parameter is one of the clue in the in multipart response:
As with other multipart types, the parts are delimited with a
boundary delimiter, constructed using CRLF, "--", and the value of
the "boundary" parameter. The boundary is supplied as a "boundary"
parameter to the multipart/form-data type. The boundary delimiter MUST NOT appear inside any of the encapsulated parts, and it is often necessary to enclose the
"boundary" parameter values in quotes in the Content-Type header
field.
Resource - https://datatracker.ietf.org/doc/html/rfc7578