Direct Internet Message Encapsulation - Problems With The HTTP

Problems With The HTTP

DIME was defined the transmission format at the data link layer in the OSI model although it was typically transmitted over HTTP. One difficulty here was that it could form an HTTP message of, essentially, any size (the limit being the size information for each chunk, which was 32 bits so 1 gigabit). Many HTTP receivers were unused to messages as large as this, and if they buffered messages would simply fail, expecting a short message and receiving a huge one. Moreover, if the HTTP receiver was secured, it would, on receiving the message, send back a challenge message (400 code) to the sender. Because HTTP is connectionless, it would then entirely lose the possibly huge amount of data that had been sent to it, just to accept or deny the challenge. There was no entirely satisfactory solution to this. The response to the challenge could of course succeed, at the expense of sending the data twice, which if it were huge rather defeats its point. (It is fair to say any other method of sending data over HTTP suffers the same problem.) In the alternate, and probably better solution, the criteria for a successful challenge (e.g. a username and password) is established out-of-band, so it can be sent with the message the first time and not receive a challenge (the by-product of the connectionless HTTP protocol being that since each message is treated individual, any message must be able successfully to include its challenge response).

DIME was extremely fast compared to practical applications of other protocols. Because the data was binary rather than, say, Base64 encoded, it was relatively compact, and the chunking and packet methods built into the protocol meant it could be streamed and read by a suitable receiver before the whole message had been read.