Subject: Re: status code for header fields to big

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Jul 2011 15:23:42 +0200

On 2011-06-30 19:17, Roy T. Fielding wrote:
> On Jun 30, 2011, at 5:46 AM, Julian Reschke wrote:
>
>> So 413 doesn't seem to be used in general for this case.
>>
>> Should it? In that case we should clarify the spec...
>
> We should define new 4xx codes for header block too long and
> header field too long.
>
> ....Roy

We could, but I really really believe we shouldn't try in the context of 
HTTPbis. If we open pandora's box right now it'll be hard to argue 
against other additions.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Jul 2011 16:18:55 +0200

On 2011-07-01 05:52, Mark Nottingham wrote:
> Personally - I think 413 is good for this; the response body and/or headers can fine-tune as to why it was rejected (as with any other error response).

I'm not totally convinced; maybe we can treat this as a separate issue 
("expand scope of 413"?), and make progress on #282 independently of it?

> Recall that we've already tuned the definition of 413 to say
>
>     The server is refusing to process a request because the request
>     representation is larger than the server is willing or able to
>     process.
>
> note 'representation' -- which includes headers.

"Entity", as used in 2616, included the headers as well; so this was 
just a terminology update, right?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Jul 2011 18:51:54 +0200

On 2011-07-01 16:18, Julian Reschke wrote:
>> Personally - I think 413 is good for this; the response body and/or
>> headers can fine-tune as to why it was rejected (as with any other
>> error response).
>

I have opened <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/299> 
for this question.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 1 Jul 2011 10:41:53 -0700

On Jul 1, 2011, at 6:23 AM, Julian Reschke wrote:

> We could, but I really really believe we shouldn't try in the context of HTTPbis. If we open pandora's box right now it'll be hard to argue against other additions.

Defining status codes does not add to the protocol -- it is just a refinement
of the existing 400 default.

....Roy

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 01 Jul 2011 17:04:43 -0700

On 06/30/2011 04:33 PM, Dzonatas Sol wrote:
> On 06/30/2011 10:17 AM, Roy T. Fielding wrote:
> How many consider the length of the query string already given as the 
> initial max length of the header lines; this could be an optimization 
> to prefetch memory regions; the given length is the first read only 
> well-known cookie from the client. Quadcores may just want the scalar 
> value; four lines; 1k each, ascii. That's a lot of headers!
>

That also aligns with how VMs currently "balloon" for/in space on 
process startup. Code pages and lines, I just haven't mentioned how this 
affects time scales; more-or-less compute units for each udp; quaternion 
compatible matrix in-line, with separate domain for each core. There is 
no well-known explicit time-scale to tera-scale standard except standard 
deviation and moore's law. This doesn't mean much for those thinking 
only in user-mode, leftovers; seconds? Quad-seconds. "Proving 
quantum/seconds," possible. Current probability of gaseous networks? 
Well, we see them "in space"; we need another word to describe them 
other than scarce; sparkles? Sparse. At VM level, sparse balloons? No. 
They just want the html-body kept in user-mode and use sockets for the 
headers in kernal-mode, default page size (by lines). Subsystems are 
parallel systems in hypertext-mode; where do the balloons after you let 
go after startup, to space? Virtual "banks" upon deposit; "any interest 
in this balloon?"

The difference is known; size matters.

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 01 Jul 2011 21:45:52 -0700

Before I sound like "a" total idiot, my bias is fuel cells. The 
perspective from battery systems explains my paragraph flow "objective". 
Once you design dynamic compilers, you never stop; all wait states are 
guru meditation errors. If you know the perodic elements, we deviant 
with those standard numbers, and assume all powers-of-two are probable. 
Thinking outside the blackbox, "cloud-computers." Private is private. 
Ugh, thanks, and E=mcc & pi=3.33... margin of error is common.

On 07/01/2011 05:04 PM, Dzonatas Sol wrote:
> process startup. Code pages and lines, I just haven't mentioned how 
> this affects time scales; more-or-less compute units for each udp; 
> quaternion compatible matrix in-line, with separate domain for each 
> core. There is no well-known explicit time-scale to tera-scale 
> standard except standard deviation and moore's law. This doesn't mean 
> much for those thinking only in user-mode, leftovers; seconds? 
> Quad-seconds. "Proving quantum/seconds," possible. Current probability 
> of gaseous networks? Well, we see them "in space"; we need another 
> word to describe them other than scarce; sparkles? Sparse. At VM 
> level, sparse balloons? No. They just want the html-body kept in 
> user-mode and use sockets for the headers in kernal-mode, default page 
> size (by lines). Subsystems are parallel systems in hypertext-mode; 
> where do the balloons after you let go after startup, to space? 
> Virtual "banks" upon deposit; "any interest in this balloon?"
>

--

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 3 Jul 2011 16:53:09 +0200 (CEST)

On Thu, 30 Jun 2011, Dzonatas Sol wrote:

> initial max length of the header lines;

My guess? Exactly none. That seems like a crazy way to get an arbitrary limit 
that won't interoperate at all.

-- 

  / daniel.haxx.se

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Jul 2011 07:59:07 -0700

On 07/03/2011 07:53 AM, Daniel Stenberg wrote:
> My guess? Exactly none. That seems like a crazy way to get an 
> arbitrary limit that won't interoperate at all.
>
Works when you do not know the limits of the substructure and you need 
something known, quick, non-stop.

Just seems crazy until you consider pads on the query strings, which 
seemed useless before.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Jul 2011 09:52:19 -0700

Proof: compare pi-r-squared to pi-r-sphered.

Guru meditation error if that caused you to wait for the answer, yes, 
"to the power of spheres".

K.I.S.

On 07/03/2011 07:59 AM, Dzonatas Sol wrote:
>>> How many consider the length of the query string already given as 
>>> the initial max length of the header lines;
>>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Jul 2011 10:24:07 -0700

Due to an off-list discussion, I should mention the concept of 
virtualization in "bubbles". It's the process of phases changes and 
possible computations (now simplified to phase-change-memory), requires 
stateful-transfers (so some think non-stateless discussions is 
off-topic). There is nothing metaphorical about these ideas in the 
hydrogen economy, the connection is obvious with those that are familiar 
with memory technology (sticky subject).

On 07/03/2011 09:52 AM, Dzonatas Sol wrote:
>> Works when you do not know the limits of the substructure and you 
>> need something known, quick, non-stop.
>>

--

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 3 Jul 2011 22:22:48 +0200

> with memory technology (sticky subject).

Dzonatas, almost all of your mails are totally off-topic and really not
related to HTTP. Here on this list, people are subscribed to discuss
protocol issues and possible solutions. Please don't use the list's
bandwidth for unrelated discussions.

Thank you,
Willy

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Jul 2011 13:38:17 -0700

We already solved the Turing-test, and need not prove this again, and 
again, and not to you. That is the attitude spam has done to machines, 
and we learned to make such arguments done more efficiently. I do not 
eat spam, liberal doesn't mean that choice is pre-made. Simply ask for 
"clarification," instead, is the more polite path than your 
"totally"-dude attitude.

HTTP affects many people, and you can not simply sweep them under the 
rug like they mean nothing in common.

We are beyond proof-of-concept, and we try not "to brag about it," or be 
so prejudice (obvious without public discussion, "RFC").

We already started and ended the discussion elsewhere: "Hydrogen 
Economy" (using "current" technology for proving that bitcoins are 
tangible and reversible).

https://forum.bitcoin.org/index.php?topic=25408.0

Q.E.D.

[We know people are pissed, that is outside the scope of this list, the 
door...]

--

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 3 Jul 2011 22:43:05 +0200

> "clarification," instead, is the more polite path than your 

Welcome to my .procmail filter then, now going to /dev/null.

Willy

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 03 Jul 2011 14:50:41 -0600

<hat type='AD'/>

> bandwidth for unrelated discussions.

Agreed.

Dzonatas, if you continue to stray off the topic, I shall ask the list
administrators to moderate your postings to the list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dale Anderson <[email-masked]>
Date: Sun, 3 Jul 2011 16:24:34 -0700

Hi Mark,

> Should a similar approach be taken when clients parse responses?

I think so, yes. Clients and servers should both ignore extra CRLF.

Even if the client and the server are are both netcat/stdio the client
or server at their station might want to hold down the enter button to
make some clear room on their terminal.

Similarly and with regards to your section 3.1, I like the way this
first paragraph reads Mark then..

>   Some old HTTP/1.0 client implementations send an extra CRLF after a
>    POST request as a lame workaround for some early server applications
>    that failed to read message-body content that was not terminated by a
>    line-ending.  An HTTP/1.1 client MUST NOT preface or follow a request
>    with an extra CRLF.  If terminating the request message-body with a
>    line-ending is desired, then the client MUST include the terminating
>    CRLF octets as part of the message-body length.

I think the text reads better without giving the flawed example implementation.

In the interest of robustness, client and server applications that are
expecting to read a request or response line should not abjure all
hope and connections if the line is empty (just CRLF). Try again, your
request-line will come, don't abort this connection..

Regards,

Dale Anderson