Content-header and content-length SHOULD requirements

[Zteve]

Hi,
I've looked in this group but the subject references are long and
complicated.

I see that there are two SHOULD requirements in the 1.1 specification
concerning content-length and content-type settings.

They are:
The SEND, MESSAGE and ERROR frames SHOULD include a content-length
header if a frame body is present. If a frame's body contains NULL
octets, the frame MUST include a content-length header.

and:

The SEND, MESSAGE and ERROR frames SHOULD include a content-type
header if a frame body is present. It SHOULD be set to a mime type
which describes the format of the body to help the receiver of the
frame interpret it's contents. If the content-type header is not set,
the receiver SHOULD consider the body to be a binary blob.

I need some clarification about the force of the SHOULDs here.

The case I have in mind is when a content-type is missing (the client
didn't supply one) and the content-length is ALSO missing. In that
case, since the server only SHOULD interpret that as binary (what is
'binary blob', please -- this isn't a Binary Large OBject, is it?)
what is the alternative? Could it, for example, reject it (return an
ERROR frame): on the grounds that it cannot determine the length
(knowing nothing about the content) and if it terminates at the first
NULL octet it is more than likely to be wrong.

If it MUST interpret it as binary and MUST assume it is terminated
with the first NULL, then why did the spec say SHOULD?

If I interpret it correctly:

o When the client SHOULD do something, I guess it means she needn't.

o When the server SHOULD do something, I guess it means it must.

Thank you for your time,
Steve Powell (A happy bunny)

[Hiram Chirino]

The content-type header does not affect STOMP framing at all. Most
stomp server should not care at all about it. The 'content-type'
header is new in STOMP 1.1 and exists so that decoupled applications
can use a standard header to describe the message payload. If it's
missing, we are just saying the apps should consider the payload to be
an opaque binary which is not described and it may or may not contain
null bytes.

The content-length header on the other hand does affect STOMP framing.
If it's missing, the frame ends at the first null byte. This means
the if your sending a message payload that contains an embedded null
byte, then it MUST set the content length to be properly framed.

This is why as of STOMP 1.1, we recommend that frame always specify
the content-length. It's the safer, and simpler. But technically its
not required if your not sending messages with null bytes. This comes
in handy if your manually doing a telnet session with your STOMP
server and typing out stomp frames by hand.

Regards,
Hiram

FuseSource
Web: http://fusesource.com/

[Zteve]

Hiram,

Thank you for your clarification.  As has been pointed out in another place, the wording of the specification is unfortunate:

The SEND, MESSAGE and ERROR frames SHOULD include a content-type 

header if a frame body is present. It SHOULD be set to a mime type 

which describes the format of the body to help the receiver of the 

frame interpret it's contents.

In the second (italicised) sentence the use of the word 'set' can be interpreted as implying that the server SHOULD do something to the frame header before passing it to the receiver .  We had mistakenly assumed there was a 'default' value for the content-type, which we were attempting to insert when it was absent.  (We were setting it wrongly, but that is another bug.)

Tony Garnock-Jones has suggested that the specification make it explicit that servers or relays MUST NOT augment the headers or the content, and that the words 'set to' in the above clause be replaced with 'be interpreted as', so as to avoid the implication of a modification. Or omit the phrase altogether, as it has no force, really.

Finally, can someone remove the apostrophe in the penultimate word of the above extract in the original?

Thank you!

Steve Powell (VMware).

[Hiram Chirino]

Hi Steve,

Great suggestion. I've opened issue
https://github.com/stomp/stomp-spec/issues/36
so we can update the next revision of the spec.

Regards,
Hiram

FuseSource
Web: http://fusesource.com/