[MOBY-dev] RFC for asynchronous POST services

Tue Feb 24 23:45:44 UTC 2009

Hi everybody,
	yes, I also agree about no multi-line headers, because they could bring many
compatibility issues, and some "clever" intermediate firewall or proxy could
misunderstand them.

	José María

Edward Kawas wrote:
> 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
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 

-- 
"There is no reason why anybody would want a computer in their home" -
	Ken Olson, founder of DEC 1977
"640K ought to be enough for anybody" - Bill Gates, 1981
"Nobody will ever outgrow a 20Mb hard drive." - ???

"Premature optimization is the root of all evil." - Donald Knuth

José María Fernández González
Tlfn: (+34) 91 732 80 00 / 91 224 69 00 (ext 3061)
e-mail: jmfernandez at cnio.es		Fax: (+34) 91 224 69 76
Unidad del Instituto Nacional de Bioinformática
Biología Estructural y Biocomputación	Structural Biology and Biocomputing
Centro Nacional de Investigaciones Oncológicas
C.P.: 28029				Zip Code: 28029
C/. Melchor Fernández Almagro, 3	Madrid (Spain)

**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en su caso los ficheros adjuntos, pueden contener información protegida para el uso exclusivo de su destinatario. Se prohíbe la distribución, reproducción o cualquier otro tipo de transmisión por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies.