What are the mechanisms/approaches to validate the UDP payload in case of SIP? SIP message doesn't contain size of header or the body, so how to verify that the payload is valid? In contrast, RTP indicates the size, so given the length value from UDP header it is possible to check RTP for validit and integrity. Can something similar be done for SIP?
Mark.
Your question has two parts:
How do I validate SIP headers? The only way to validate SIP headers is to parse them according to the rules of section 7.3.1 of RFC 3261. There are SIP parsers available for many different languages.
How do I validate the body of SIP messages? There is a mechanism built into SIP: the Content-Length header specifies the size of the body. In the general case, the body can contain an arbitrary MIME type, and no further validation rules apply.
Edit: Per Frank Shearar's comment below, Content-Length is not required for SIP messages conveyed via UDP. But if your UA supports it, you can take advantage of it.
Related
I'm implementing a ultra simple dummy HTTP server responding a message with Hello world to any requests. It is just for benchmarking the asynchronous event handling with wrk or equivalent web server benchmarking tool.
After some searching on the Web I can't find a clear EndOfMessage (EOM) marker. It seam that with HTTP 1.0 we know we have received the full request when the connection is closed. Is that right ?
For HTTP 1.1, how do we know if pipelining is used ? What is the EOM in this case ?
After some searching on the Web I can't find a clear EndOfMessage (EOM) marker.
You can't find one because such a thing doesn't exist. The only marker you may find is the CRLF pair indicating the end of the header fields. In general, the enclosed entity length (that is for requests and responses!) is either communicated beforehand via the Content-Length header or through the transport coding.
with HTTP 1.0 we know we have received the full request when the connection is closed. Is that right?
That is one of two ways mandated by RFC 1945. So generally speaking: no. From RFC 1945, section 7.2.2:
When an Entity-Body is included with a message, the length of that body may be determined in one of two ways. If a Content-Length header field is present, its value in bytes represents the length of the Entity-Body. Otherwise, the body length is determined by the closing of the connection by the server.
This may read like you were generally in the right with your assertion. BUT:
Closing the connection cannot be used to indicate the end of a request body, since it leaves no possibility for the server to send back a response.
With you being on the receiving side, your assumption is simply wrong on every conceivable level: If the request contains a body, announcing the size of said body through the Content-Length header is an absolute requirement.
HTTP/1.1 is a bit relaxed in this regard, as it allows for more options. As Julian pointed out, please consult RFC 7230, section 3.3.3. That section is straightforward to read and to answer your question, I'd have to c&p it as whole.
For HTTP 1.1, how do we know if pipelining is used ?
You do if you receive multiple requests through one connection. The strongest indicator for the client non engaging into pipelining is the presence of Connection: close in the first received request. See RFC 7230, section 6.3 and section 6.3.2. If you are worried about having to support this, you are always free to just read the first request and send back a response with Connection: close in it. The client will know it has to establish a new connection.
What is the EOM in this case ?
Again, there is no marker as there is no special treatment for requests during pipelining. All pipelining is really enabling is to have multiple requests being issued in one go. See section 3.3.3 from above on how to determine the message length.
I was thinking about JSON/XML-RPC over HTTP vs TCP. In case of HTTP, the HTTP request and response provide a message framing mechanism. However, since TCP is a stream,
How are RPC messages framed?
Does the RPC spec dictate that?
Are there any other standards defining framing mechanisms?
Is there one mechanism more often used than the other?
I'm trying to guage this before inventing a framing mechanism.
There are many framing standards, HTTP being one of them. Websocket being another, on top of HTTP, more suited for bidirectional streams.
JSON-RPC 2.0 does not concern itself with transport, intentionally.
(1.0 had some transport specifics, that was removed in the new version.)
RFC 7484 provides a framing standard for "JSON text sequences": https://www.rfc-editor.org/rfc/rfc7464
Summary: Each JSON message is prefixed with a 0x1E byte (which can't appear unescaped in a JSON message) and is suffixed with 0x0A (linefeed).
Note, however, that this is not part of the JSON-RPC specification. There are libraries that support it as part of their JSON-RPC implementation.
I am testing the Last.fm api using row socket interface.
Now i noticed that some of api's http response have not contain a field Content-Length .
But I want to know is there a way to ask the server presenting it?
Because i can't take good care of this in my program elegantly.
Quoth the RFC:
7.2.2 Length
When an Entity-Body is included with a message, the length of that body may be determined in one of two ways. If a Content-Length header field is present, its value in bytes represents the length of the Entity-Body. Otherwise, the body length is determined by the closing of the connection by the server.
The right RFC to look at is RFC 7230 (Section 3.3.2).
And no, in HTTP/1.1 a client has to be able to process chunked encoding (which would be the only legitimate reason not to provide a Content-Length header field).
I have a doubt regarding sending of mime attachments over HTTP:
in http specs the following is quoted :
“C.4 No Content-Transfer-Encoding: HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 1521. Proxies and gateways from MIME-compliant protocols to HTTP must remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client. Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway should label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.”
Does this mean that specifically for sending MIME attachments only over http, we shouldn't specify content-transfer-encoding as quoted-printable or base64 ?
Also, what is the behavior of conetent-transfer-encoding when i send such attachments over other transports like JMS, or over Mail? For example in a SOAP over JMS message?
Also the found following relevant from RFC 4130 :
“5.2. Unused MIME Headers and Operations
5.2.1. Content-Transfer-Encoding Not Used in HTTP Transport
HTTP can handle binary data and so there is no need to use the content transfer encodings of MIME [1]. This difference is discussed in [3], Section 19.4.5. However, a content transfer encoding value of binary or 8-bit is permissible but not required. The absence of this header MUST NOT result in transaction failure. Content transfer encoding of MIME body parts within the AS2 message body is also allowed.”
So i am basically thoroughly confused over the behavior of mime attachments specific to the HTTP protocol, and would like to get its behavior clarified.
HTTP is not MIME, it just borrows from the MIME message format. Payloads in HTTP are binary, and there simply is no Content-Transfer-Encoding header field. You can specify it, but it has zero effect and keeps distracting people looking at wire traces.
As I understand, TCP has a relatively reliable checksum mechanism, but there is a very small yet present chance of it returning a false positive.
Does HTTP use an application level checksum (perhaps a hash)? If not, why?
Yup (: the specs for HTTP/1.1 (RFC 2616) allow the use of a Content-MD5 header. Take a look at its section 14.15.
Copy-pasted:
The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
an MD5 digest of the entity-body for the purpose of providing an
end-to-end message integrity check (MIC) of the entity-body.