Re: [stomp-dev] Fwd: I want my MOM

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [stomp-dev] Fwd: I want my MOM

Sean E. Russell
On Friday 28 October 2005 18:10, H. William Welliver III wrote:
> > About the space after the colon: why include a space?  I don't see
> > a need
> > for it.  -1.
>
> In the same vein, why then exclude it? There's plenty of HTTP and
> MIME parsing code that could be leveraged here, I see no reason for
> breaking with convention simply for the sake of it. Personally, I
> think the space following the colon makes things easier to read, but
> that's just me.

Because requiring it is adding a rule.  A small one, but it is another rule.  
Now, I have to check to make sure that it is there, and it is an error if it
isn't.  One more thing for somebody to mistype; one more thing to break.  And
if some people get their way, a small error like a missing space will get you
booted from the server.

I don't really care that much about it; I just prefer less rigidity.

--
--- SER

"As democracy is perfected, the office of president represents,
more and more closely, the inner soul of the people.  On some
great and glorious day the plain folks of the land will reach
their heart's desire at last and the White House will be adorned
by a downright moron."        -  H.L. Mencken (1880 - 1956)

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [stomp-dev] Fwd: I want my MOM

Bill Welliver
>
> Because requiring it is adding a rule.  A small one, but it is  
> another rule.
> Now, I have to check to make sure that it is there, and it is an  
> error if it
> isn't.  One more thing for somebody to mistype; one more thing to  
> break.  And
> if some people get their way, a small error like a missing space  
> will get you
> booted from the server.
>
> I don't really care that much about it; I just prefer less rigidity.

But if the syntax is no spaces, and a client is lenient but the  
server is not, then having a space will change either the key or  
value, which means data corruption. If you say that it can be either/
or, then you'd probably also need to say that any leading or trailing  
whitespace would have to get trimmed, which is in itself another  
rule. I'm not trying to be argumentative, just pointing out that it's  
not really any simpler either way.

Best,

Bill
Reply | Threaded
Open this post in threaded view
|

Re: [stomp-dev] Fwd: I want my MOM

brianm

On Oct 28, 2005, at 8:29 PM, H. William Welliver III wrote:
>
> But if the syntax is no spaces, and a client is lenient but the  
> server is not, then having a space will change either the key or  
> value, which means data corruption. If you say that it can be  
> either/or, then you'd probably also need to say that any leading or  
> trailing whitespace would have to get trimmed, which is in itself  
> another rule. I'm not trying to be argumentative, just pointing out  
> that it's not really any simpler either way.

Right now, I am pretty sure, the spec says whitespace is trimmed from  
around the key and the value.

-Brian

>
> Best,
>
> Bill
>

Reply | Threaded
Open this post in threaded view
|

Re: [stomp-dev] Fwd: I want my MOM

Jeff Tupholme
In reply to this post by Sean E. Russell

I think RFC822 (used in HTTP, SMTP and I'm sure elsewhere) is
pertinent. The 'long header fields' section doesn't appear to mandate a
space, although I believe using one is common practice for readability.
Personally, I'd go along with Bill.

  http://www.ietf.org/rfc/rfc822.txt


Jeff


On 28 Oct 2005, at 11:10pm, H. William Welliver III wrote:

>> About the space after the colon: why include a space? I don't see a
>> need
>> for it. -1.
> In the same vein, why then exclude it? There's plenty of HTTP and MIME
> parsing code that could be leveraged here, I see no reason for
> breaking with convention simply for the sake of it. Personally, I
> think the space following the colon makes things easier to read, but
> that's just me.
>
>>>>> 7) State that ":" is not a valid header. This means that they can't
>>>>> send empty headers.
>>>>>
>>>
>>> +1
>>>
>>
>> Why not? Seriously? What is the problem with having "" => "" in a
>> hashtable? For that matter, what's wrong with having "" => "foo"
>> (:foo)
>> or "foo" => "" (foo:). I think both are useful. Allowing the two
>> latter
>> implies that the former is valid unless a special rule is made to
>> disallow
>> it, and that seems to be cruft.
> Again, what do other commonly implimented specs say about this?
> Personally, I'd disallow empty header keys, along with spaces, newline
> delimeters and the key-value delimiter (:) in keys, but allow
> everything except new line delimiters (and maybe nulls?) in the
> values. 
>
> Bill