[MOBY-dev] RFC for asynchronous POST services

[Edward Kawas]

Yeah, I just wanted to throw out the other option for consideration. Besides
encoding/decoding overhead, there is also a doubling of the message side if
we went that route. I agree, no new lines. 

Anyone with any objections?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: February-24-09 10:57 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

I vote for strongly encouraging no new lines in the XML, and warning 
implementers that it might crap out if they include any. I HATE base64 
encoding and decoding messages!  Kind of defeats the purpose of using 
XML in the message in the first place...

BTW, I can confirm after scouring the Web for info that lots of programs 
(e.g. Microsoft IIS, IBM Websphere) have run into problems with 
multi-line headers, even in the last couple of years.

Edward Kawas wrote:
> You bring up a very good point. I think that we could either agree to use
no
> new lines. 
>
> Another, less desirable, option might be to base64 encode the header... I
> like your idea more though (I like sitting on the fence ...)
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:43 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> According to RFC2616, which references RFC822 section 3.1, you can 
> indeed have multi-line header field value, as long as each extra line 
> starts with some linear white space.  Otherwise it'll think a new line 
> is a new header (and probably a malformed one at that).  There is a 
> standard for "folding" and "unfolding" such multi-line headers, which 
> essential strips CR and LF out of the message on the receiving end.  I'm 
> not sure how well this folding and unfolding protocol is handled by 
> various servers and clients, but given that new lines will be stripped 
> out on the receiving end anyway, should we say that the biomoby-wsrf 
> field XML value should have no new lines, for maximum likelihood of 
> transactional success?
>
> Edward Kawas wrote:
>   
>> Hi Paul,
>>
>> I was thinking of just treating that XML doc as a string and placing that
>>     
> as
>   
>> the value for the header with key biomoby-wsrf.
>>
>> Do you think that will work?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:17 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> Hi Eddie,
>>
>> Pardon my ignorance, I was quickly perusing the document, but in the 
>> document where you break down sample XML such as "Response from 
>> destroying the resource", how exact do you put that XML block in the 
>> header?  I though HTTP headers are usually name=value...
>>
>> Edward Kawas wrote:
>>   
>>     
>>> Hello all,
>>>
>>> Attached is a draft proposal describing asynchronous post services in
>>>     
>>>       
>> moby.
>>   
>>     
>>> It is very similar to the RFC for moby-async services, except that it is
>>> HTTP POST and not SOAP based.
>>>
>>> Be harsh but nice!
>>>
>>> Eddie 
>>>   
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>     
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev