Hacker News new | past | comments | ask | show | jobs | submit login

> stupid J2ME clients that send chunked-encoding when they aren't supposed to (it's for servers morons).

Sorry, Mr. Shaw, but you are wrong (but I still like you and I'm looking forward to Mongrel2).

RFC 2616 is careful to say 'server' when it means servers and 'client' when it means clients. Section 3.6.1 specifically states that HTTP/1.1 applications (so both clients and servers!) MUST support chunked encoding.

The developers of that Java HTTP client (Jakarta?) seem to have read the spec more thoroughly than you did. :-)




Furthermore, Chunked to the client is having a renaissance at the moment thanks to the BigPipe ideas coming out of Facebook. Speaking of which, Mongrel2 will be a tremendous server for apps that need this optimization.


No, this is chunked from the client, not to the client. To the client is quite alright and works great. From the client is absolutely retarded and total abuse of the protocol.

Which brings up another point: HTTP is like the old testament. Wanna kill your brother? Probably find something to support it. Wanna sacrifice a goat? Yep, you could do that. Don't want people to sacrifice goats? Sure, rock on. Want adultery? You could probably find that too. It's got everything depending on what you read, where you read, and what context you take it in.

The HTTP RFC is like that. Want to send chunked encoding mixed inside a keep-alive with request pipelining when you don't really need to? Rock on. Want google web accelerator to hit links without you asking it to (in clear violation of every other part of the browser standard)? Go for it. Don't want people to do that? Cool there's another part.

After a while, you have to go with what's most probable, and just be explicit in your own design about the rest.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: