RE: Summing up on visibility(?)

The point is, HTTP PUT doesn't tell me if I'm changing my phone number in
the company directory or adding $1b to my bank account, and HTTP GET implies
that the operation has no side effect, but without any guarantee as far as
intermediaries are concerned. We know from reality that software does not
always behave as advertised.

You can't draw much conclusions by just looking at the HTTP method, and you
don't have to. Firewalls, caches, MOMs and <insert-you-favorite-hop-here>
all have SOAP functionality or getting some.

The days when all they would do was peek at the first TCP packet to
determine which HTTP method it is - and miss all subsequent methods if HTTP
1.1 keep-alive was used - are over. Now they look beyond the first packet,
and they look at the content, and they try to understand what that content
implies.

Because as I said before, firewalls don't work on best intentions, and XML
accelerators don't just route GET to the left PUT to the right. The real
requirements are more complex, and the products are stepping up to the task,
and as Mike correctly said much of the visibility arguments were really good
in 1996 but are no longer relevant in 2003.

arkin


> Ok, I *really* don't want to open this up again full-blown, but I just
> have to ask ...
>
> On Thu, Jan 09, 2003 at 07:15:01PM +0000, Miles Sabin wrote:
> > Well, I don't believe that application-level semantics are likely to be
> > accessible to anything, intermediary or otherwise, without it having
> > some sort of prior knowledge of those semantics (this is just the good
> > ol' end-to-end principle).
>
> Wouldn't the prior knowledge of HTTP application semantics by an HTTP
> intermediary qualify?  I would agree that, for example, an SMTP message
> isn't visible to an HTTP intermediary.  But there's shared knowledge
> on application semantics in the HTTP/HTTP case.
>
> I'm not trying to conclude the previous thread.  Just hoping that we can
> find agreement on *some* degree of loss in visibility with the method
> in the body.
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>

Received on Thursday, 9 January 2003 16:36:15 UTC