Subject: HTTP Batch Request Draft

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 12:00:38 -0700

FYI: http://www.ietf.org/internet-drafts/draft-snell-http-batch-00.txt

This is an initial draft and comments/feedback are requested and 
desired. Thank you,

- James

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 08 Jun 2009 23:40:03 +0200

>This is an initial draft and comments/feedback are requested and 

It is not clear why you are using application/http; the main difference
to message/http is that you supposedly can specify many requests or re-
sponses (in practise that is difficult because you cannot properly de-
tect message boundaries without knowing requests and responses, but you
cannot specify them together), and your type pretty much assumes that
you have individual messages anyway (the draft refers to individual re-
quests throughout).

The introduction should note at least some of the limitations of pipe-
lining if there are a number of them. I would rephrase it wholesale so
it explains how it complements pipelined requests instead of merely
noting that it is not meant to replace it.

The RFC 2119 keywords should be in a separate section on terminology;
the introduction is meant to explain what the document is about, not
how to read it.

It might be better to refer to Internet media types as media types,
not content types (also beware confusing "content type", "content-
type" and "Content-Type").

I initially did not understand "Each part in the batch MUST share a
common Content-Type as specified by the Multipart/Batch content types
Type parameter"; later I realized what you want to say is that all
the individual parts must be of the type specified in the "type" pa-
rameter. Please rephrase that. It might be a good idea to merge this
with the section defining the parameter.

You should have a reference to the definition of the Content-ID header.

The use of "Server: example.org" is confusing, do not use strings that
look like domain names there.

You say how to handle parts that do not specify the expected Content-
type header, but do not say how to handle parts that fail to meet the
requirements for Content-ID and In-Reply-To. It is not clear to me that
In-Reply-To is the right header to use.

The type registration fails to meet requirements of RFC 4288. It is
also contradictory, type for example seems incorrectly defined as it
would seem that parameters are prohibited.

As you primarily intend it to use with HTTP, I am unsure if it is a
good idea to define a far more general type. Also, given the focus on
HTTP, you ought to say a few things about e.g. detecting message
boundaries (if a part is N bytes long but the Content-Length header or
chunks in the message lead to a length of M, what then?)

You should add a line of text to the Abstract per the I-D guidelines.
Good to know though that drafts with less than 3 lines are no longer
rejected...

I do not think the draft should require that responses appear in the
order of the requests.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 8 Jun 2009 23:55:11 +0200 (CEST)

On Mon, 8 Jun 2009, Bjoern Hoehrmann wrote:

> I initially did not understand "Each part in the batch MUST share a common 
> Content-Type as specified by the Multipart/Batch content types Type 
> parameter"; later I realized what you want to say is that all the individual 
> parts must be of the type specified in the "type" parameter. Please rephrase 
> that. It might be a good idea to merge this with the section defining the 
> parameter.

Why is that header needed in the first place if it MUST be the same in all the 
parts and it MUST be the same as is provided already?

And a minor note: the example request in 2.2 would look more proper in my eyes 
if it used Content-Length: for the main POST too.

-- 

  / daniel.haxx.se

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 15:00:22 -0700

Bjoern,

Thank you for the detailed comments. As you have pointed out, much of 
the prose around the technical details is definitely lacking. As an 
initial draft, my intent was mainly to get the basic mechanism down and 
to fix up the prose in subsequent iterations of the document.

> you have individual messages anyway (the draft refers to individual re-
Ok, so I had to glance back at the definitions in RFC2616 and yes, 
message/http would appear to be the correct option in this case. I 
managed to get the definitions mixed up in my head (not a difficult task 
to say the least)
> noting that it is not meant to replace it.
Noted. I already had such an edit planned for a future iteration.
> the introduction is meant to explain what the document is about, not
Noted.
> type" and "Content-Type").
Noted.
> look like domain names there.
Noted.
> In-Reply-To is the right header to use.
Good point. I will add that in. Basically, if a batch response does not 
contain a response to an individual batched request, the client should 
treat it no differently than if the server failed to respond had that 
batched request been sent by itself. The result of the request would be 
indeterminate.  If the batch response includes parts that do not 
correlate to parts in the batch request, then the client should ignore 
those parts.
> would seem that parameters are prohibited.
Noted.
> chunks in the message lead to a length of M, what then?)
Noted. These are precisely the kinds of technical details I am hoping to 
flesh out in subsequent iterations of the draft.
> Good to know though that drafts with less than 3 lines are no longer
Noted.
> I do not think the draft should require that responses appear in the
I've gone back and forth on this one and settled on the current 
"SHOULD". I am definitely not opposed to relaxing that tho. 
Realistically, a server will order the responses based on whatever 
mechanism it determines appropriate for processing the requests.

- James

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 15:05:34 -0700

Daniel Stenberg wrote:
>> the individual parts must be of the type specified in the "type" 
>> parameter. Please rephrase that. It might be a good idea to merge 
>> this with the section defining the parameter.
>
> Why is that header needed in the first place if it MUST be the same in 
> all the parts and it MUST be the same as is provided already?
>
Good point. We can likely drop the per-part Content-Types.
> And a minor note: the example request in 2.2 would look more proper in 
> my eyes if it used Content-Length: for the main POST too.
>
Noted and agreed.

- James

---

From: Patrick McManus <[email-masked]>
Date: Wed, 10 Jun 2009 09:16:04 -0400

"Once the batched request messages have been processed, a single HTTP
   Batch Response message is created wherein each part contains the HTTP
   Response Messages."

This seems to mean the server cannot begin to generate any response
until all portions of the request have been received. That would seem to
recreate the same head of line blocking problem on a connection we
already have with pipelines. 

   "To simplify client processing of the response, the ordering of
   response messages in the Batch Response SHOULD match the ordering of
   request messages in the Batch Request."

huh? The value I see in your proposal is that it allows out of order
responses which could improve latency for requests that would other wise
be "stuck-in-line". So why would you recommend against your strongest
(only?) feature. The client has to correlate the ID's anyhow - so its
not like you've made it easier.  

hth.

-- 
PenBay Networks
VOIPRecorder - Record Calls Made with Vonage(tm) on Your Computer!
www.penbaynetworks.com

---

From: James M Snell <[email-masked]>
Date: Wed, 10 Jun 2009 09:25:13 -0700

> already have with pipelines. 
I know this is probably not the answer you'd like to hear but that's 
actually not a problem we're looking to solve with this.
> not like you've made it easier.  
The next version of the draft will remove this SHOULD and allow the 
responses to be in any order.

- James

---

From: Patrick McManus <[email-masked]>
Date: Wed, 10 Jun 2009 12:48:50 -0400

> actually not a problem we're looking to solve with this.

which begs the question - what are you trying to solve?

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Jun 2009 14:55:15 +1000

My initial reaction is that I'm not a fan.

It seems to me that this encourages tunnelling over HTTP to overcome  
the limitations of pipelining and other aspects of the connection.

While there may be some places for it, I think it'll end up being used  
indiscriminately, reducing the amount of visibility into the protocol  
that the infrastructure gets.

The right way to fix these problems is to fix the underlying transport  
issues; e.g., see the discussions around HTTP over SCTP. In the  
meantime, applications that need this type of functionality can define  
local use of POST to do the same thing...

Cheers,

--
Mark Nottingham     http://www.mnot.net/