Re: can GET do for QUERY? extending Partial Content

On Wed, Apr 29, 2015 at 06:53:36PM +0200, henry.story@bblfish.net wrote:
> >> Is this hypothetical problem the only one?
> > 
> > What is hypothetical is not the problem but your belief that you can
> > inventory all cases of trouble in a finite time by doing some research.
> 
> I was not thinking about other deployment problems. I was thinking of
> architectural problems and logical flaws with this proposal. I like to
> build things that are correct at all levels.
> 
> I mean if the logical and architectural problems are all solved, then
> fine we can look at the deployment issues. But it would be silly to waste
> time on the research if even after we gathered all the information there we'd
> find that architectural problems remain.
> 
> But hey if you and everybody else here thinks that deployment is the only
> issue left here, then that would be good to know. :-)

The difference between theory and deployment is covered by the difference
in number of pages between RFC2616 and RFC723x. Without that, the standard
would be much much simpler and cleaner, and there would be almost no SHOULD.

I really think you're minimizing the size of the problem here.

> >> Perhaps we can put this aside
> >> for the time being and see if there are other issues that are problematic. 
> > 
> > Well you can use it between your own components, but you'll have a hard
> > time explaining to all your users that their freshly acquired products
> > which used to respect standard still 2015 are not standard-compliant
> > anymore past 2015. At least with Upgrade we had the ability to play on
> > the compliance side to convince vendors to fix their crap and sell their
> > fixes as feature updates ("support for websocket and HTTP/2").
> 
> Again defining something that is undefined does not break a standard.
> The latest spec says that GET can have Content-Length header. Presumably
> the people allowing this had their reasons. Perhaps this is it.

The first reason is to simplify the implementations : when you see that
you have no reason for doing a special case of GET when you already support
POST, PUT and any other method supporting a body, you ensure that it works
just like the other ones. Conversely, when you don't expect to need a body,
you simply don't implement this at all and whatever follows the headers is
processed in the easiest way for your implementation. I used to see a NAS
segfault when receiving a body after a GET request or even pipelined GET
requests, I've seen products block the body (and wrote one which used to),
others will silently drop it. In fact you're very lucky when you get an
error because you can react quickly. All other cases are painful because
users say "it doesn't respond, even after one minute" and nobody knows
where to look at.

Willy

Received on Wednesday, 29 April 2015 17:09:17 UTC