Subject: [core] Block GETs beyond resource size

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 13 Jan 2012 02:40:30 +0000

Hi all,

While reviewing the Block draft, I noticed that there are not yet much error cases considered.

I am particularly wondering about a GET request from the client to the server, for a block beyond the size of the resource. For example, what will the server do when it receives a (BLOCK2, block size=512, block number=3) GET for a resource with a size of only 800 bytes?

It seems obvious that the server should send an error code. But which one? "4.00 Bad Request", "4.02 Bad Option", "4.04 Not Found", "4.06 Not Acceptable" all seem appropriate, though none of them is descriptive about the particular error.

I found that there used to be a "4.13 Request Block Error" code, but that was changed to "4.13 Request Entity to Large".

Do folks think we need to add some text about this to the Block draft, or may even need to define a new error code?

Best regards,
Bert

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Jan 2012 08:00:44 +0100

Bert,

good point.

On Jan 13, 2012, at 03:40, Bert Greevenbosch wrote:

> It seems obvious that the server should send an error code.

One other way to handle this would be to respond with a 2.05 with an empty payload and M=0.

In UNIX, this is what you get when you seek behind the EOF and try to read.

Clearly, when you GET exactly at the end (e.g., have 1024 bytes of payload and do a GET with Block2/2/0/512), you get back a zero-length payload, so there already need to be code paths handling these.

I really don't have a strong feeling whether this "seeking/reading beyond the end" needs another error code or is "normal" as it would be in UNIX.

When can this happen?  If clients follow the sequential protocol, this can only happen when the size of the resource has changed.  This should lead to a new ETag, so the client knows it cannot use the current assembly, so it will have to restart from 0.  The only adverse effect of an empty 2.05 could be that a not so bright client might allocate a new buffer to the size of the current seek position (as it meaningfully would do if it did get data).  If you "don't do that"™, there is no problem.

Once we have a Size option, sending this back in conjunction with an empty 2.05 might a nice way to respond to a Block2 seek beyond the end.

With Block1 (and PUT), seeking beyond the end might be an immediate 4.08 error for an atomic server, or it might also simply be executed (with UNIX' hole-filling semantics) by a stateless server, so I think we are covered there.

Interesting discussion!

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 17 Jan 2012 05:33:40 +0000

Hi Carsten,

Thank you for your response.

I agree that the "UNIX solution" would be a fix to the problem too.

As for when it should happen, clearly the client shouldn't send such a request in the first place. It can refrain from it, when it sends the requests sequentially, i.e. a GET request for the next block is sent only after the GET response for the previous block was received.

If the client doesn't wait for the response and sends a bunch of GETs for multiple blocks shortly after each other, it becomes more complicated. If the "size" option is included, at least it can know the number of blocks in advance, after the initial block size negotiation has taken place. If not, it may end up sending GETs beyond the last block.

With PUT, the server can detect PUTs of blocks beyond the end of the file by inspecting the "more" flag of the previous blocks, inspecting the "size" option, or by secondary means such as inspecting the payload format. In these cases, indeed it can return an error code, but it should really not happen, as the sending client knows the resource size. Could you explain why the 4.08 "Request Entity Incomplete" error code is appropriate for this case?

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 13 January 2012 15:01
To: Bert Greevenbosch
Cc: [email-masked]
Subject: Re: [core] Block GETs beyond resource size

Bert,

good point.

When can this happen?  If clients follow the sequential protocol, this can only happen when the size of the resource has changed.  This should lead to a new ETag, so the client knows it cannot use the current assembly, so it will have to restart from 0.  The only adverse effect of an empty 2.05 could be that a not so bright client might allocate a new buffer to the size of the current seek position (as it meaningfully would do if it did get data).  If you "don't do that"T, there is no problem.

Interesting discussion!

Grüße, Carsten