[squid-users] TCP_MISS only

[Andy Armstrong]

Hi,

Excellent I understand and agree with what you are saying. Is this behaviour documented within the Squid documentation anywhere, or is this more ‘how does the HTTP specification handle caching’?

I am moving forward with a HTTP GET to see if that works per my use case. I assume therefore that any other verb is simply not going to work out the box?

Kind regards,

Andy Armstrong
安迪 阿姆斯特朗
Principal Specialist for Z Technologies
EMEA Squad Leader for Hybrid Cloud
Worldwide Community Leader for Hybrid Cloud
Member of the CTO Office Server & Storage EMEA
Distinguished Technical Specialist – The Open Group
IBM Master Inventor

Mobile: +447500103874



From: squid-users <squid-users-bounces at lists.squid-cache.org> on behalf of Amos Jeffries <squid3 at treenet.co.nz>
Date: Thursday, 29 September 2022 at 13:06
To: squid-users at lists.squid-cache.org <squid-users at lists.squid-cache.org>
Subject: [EXTERNAL] Re: [squid-users] TCP_MISS only
On 28/09/22 07:56, Andy Armstrong wrote:
> Okay – but what happens if you are communicating with a non REST
> endpoint.

You are still communicating over HTTP. To interact with and benefit from
HTTP agents like caches you need to comply to the HTTP semantics they use.

IMO, REST is just a useful tool to define (in abstract) an API's
operation when considering what/how it needs to be implemented.


> Consider a Web services endpoint for example where a request
> is only interacted with via POST but the operation for example may
> frequently be a read based function akin to a HTTP GET?

That is by definition a broken implementation of HTTP. The agent is
using a *delivery* API (POST) for retrieval (GET).

If you can separate the delivery and fetch operations HTTP becomes much
easier to use.


> Is Squid just
> simply not going to help cache those requests?

Not *by default*, no.

POST implies changing some arbitrary resource *other* than the URL
presented. Based on data and logic which may not be provided in the
request message URL+headers.

To use POST with caching both the client *and* the server have to
explicitly tell the HTTP cache agent(s) what to do on every single HTTP
message.

  - The client has to tell the cache whether a stored response is able
to be produced as reply, what object-ID it is trying to retrieve, what
object-ID's it already knows about (if any), and how old the stored
object is allowed to be.

  - The server has to tell the cache whether the response can be stored,
what to use for a unique-ID of the reply object, how old it already is,
how long it can be stored for, how and when to update it when it becomes
stale.

The Squid refresh_pattern can provide defaults for the storage times
when they are omitted. But all the ID related things and whether to use
cache at all can only come from the client/server.


As you can see by limiting yourself to POST-only you have imposed a huge
amount of complexity. Using GET instead for fetches makes all the above
*optional* where now it is mandatory.


> It is only helpful for
> more strict alignment to REST principles?
>

You lost me here. Squid implements HTTP.

REST is a very abstract simplification of basic HTTP/1.0 semantics. So
the closer ones code aligns to REST the *easier* it is to implement HTTP
properly. But HTTP/1.1+ are vastly more than REST.

HTH
Amos
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20220929/ca0601a8/attachment-0001.htm>