Squid doesn't reload webpage like other clients do

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Squid doesn't reload webpage like other clients do

Troiano Alessio
Hello,
I've squid 3.5.20 running on RHEL 7.4.
I have a problem to access some websites, for example www.nato.int.
This website apply an Anti-DDoS system that reset the first connection after the TCP 3-way handshake (SYN/SYN-ACK/ACK/RST-ACK). All subsequent TCP connections are accepted. The website administrator say's it is by design.
When I browse that site directly with all browser (IE, FF, Chrome) I see the normal site showed. Anyway it is because after the first reset the client try to reload the page. I've the same behaviour also with wget:

[root@soc-pe-nagios01 ~]# wget www.nato.int
--2017-10-30 10:02:50--  http://www.nato.int/
Resolving www.nato.int... 152.152.31.120
Connecting to www.nato.int|152.152.31.120|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2017-10-30 10:02:51--  (try: 2)  http://www.nato.int/
Connecting to www.nato.int|152.152.31.120|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.nato.int/ [following]
--2017-10-30 10:02:51--  https://www.nato.int/
Connecting to www.nato.int|152.152.31.120|:443... connected.
WARNING: cannot verify www.nato.int's certificate, issued by '/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2':
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html.17'

    [      <=>                                                                                         ] 168,229      147K/s   in 1.1s

2017-10-30 10:03:39 (147 KB/s) - index.html.17 saved [168229]

When I browse the site with squid proxy the browser receive an "Empty Response" squid error page (HTTP error code 502 Bad Gateway) and doesn't do the automatic retry:

[root@soc-pe-nagios01 ~]# wget www.nato.int -e use_proxy=yes -e http_proxy=172.31.1.67:8080
--2017-10-30 10:41:09--  http://www.nato.int/
Connecting to 172.31.1.67:8080... connected.
Proxy request sent, awaiting response... 502 Bad Gateway
2017-10-30 10:41:09 ERROR 502: Bad Gateway.

I can't find an RFC that confirm if browser and proxyes should try a page reload, or if squid has an option to do that.

Any help is appreciated.

Best Regards, Alessio.

Il presente messaggio e-mail e ogni suo allegato devono intendersi indirizzati esclusivamente al destinatario indicato e considerarsi dal contenuto strettamente riservato e confidenziale. Se non siete l'effettivo destinatario o avete ricevuto il messaggio e-mail per errore, siete pregati di avvertire immediatamente il mittente e di cancellare il suddetto messaggio e ogni suo allegato dal vostro sistema informatico. Qualsiasi utilizzo, diffusione, copia o archiviazione del presente messaggio da parte di chi non ne è il destinatario è strettamente proibito e può dar luogo a responsabilità di carattere civile e penale punibili ai sensi di legge.
Questa e-mail ha valore legale solo se firmata digitalmente ai sensi della normativa vigente.

The contents of this email message and any attachments are intended solely for the addressee(s) and contain confidential and/or privileged information.
If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately notify the sender and then delete this message and any attachments from your system. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Unauthorized disclosure and/or use of information contained in this email message may result in civil and criminal liability. “
This e-mail has legal value according to the applicable laws only if it is digitally signed by the sender
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid doesn't reload webpage like other clients do

Alex Rousskov
On 10/30/2017 03:51 AM, Troiano Alessio wrote:

> I've squid 3.5.20 running on RHEL 7.4. I have a problem to access
> some websites, for example www.nato.int. This website apply an
> Anti-DDoS system that reset the first connection after the TCP 3-way
> handshake (SYN/SYN-ACK/ACK/RST-ACK). All subsequent TCP connections
> are accepted. The website administrator say's it is by design.


> When I browse the site with squid proxy the browser receive an "Empty
> Response" squid error page (HTTP error code 502 Bad Gateway) and
> doesn't do the automatic retry:

This is by design as well :-).

We can change Squid behavior to retry connection resets, but I am sure
that some folks will not like the new behavior because in _their_ use
cases a retry is wasteful and/or painful. IMHO, the new behavior should
be controlled by a configuration directive, possibly an ACL-driven one.

Quality patches implementing the above feature should be welcomed IMO.
The tip of the relevant code is probably in ERR_ZERO_SIZE_OBJECT
handling inside FwdState::fail(). There is a similar code that handles
persistent connection races there already, but the zero-size reply code
may need a new dedicated FwdState flag to prevent infinite retry loops
when the origin server is broken (a much more typical use case than the
weird attempt at DDoS mitigation that you have described above).

https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F


HTH,

Alex.



> [root@soc-pe-nagios01 ~]# wget www.nato.int -e use_proxy=yes -e http_proxy=172.31.1.67:8080
> --2017-10-30 10:41:09--  http://www.nato.int/
> Connecting to 172.31.1.67:8080... connected.
> Proxy request sent, awaiting response... 502 Bad Gateway
> 2017-10-30 10:41:09 ERROR 502: Bad Gateway.
>
> I can't find an RFC that confirm if browser and proxyes should try a page reload, or if squid has an option to do that.
>
> Any help is appreciated.
>
> Best Regards, Alessio.
>
> Il presente messaggio e-mail e ogni suo allegato devono intendersi indirizzati esclusivamente al destinatario indicato e considerarsi dal contenuto strettamente riservato e confidenziale. Se non siete l'effettivo destinatario o avete ricevuto il messaggio e-mail per errore, siete pregati di avvertire immediatamente il mittente e di cancellare il suddetto messaggio e ogni suo allegato dal vostro sistema informatico. Qualsiasi utilizzo, diffusione, copia o archiviazione del presente messaggio da parte di chi non ne è il destinatario è strettamente proibito e può dar luogo a responsabilità di carattere civile e penale punibili ai sensi di legge.
> Questa e-mail ha valore legale solo se firmata digitalmente ai sensi della normativa vigente.
>
> The contents of this email message and any attachments are intended solely for the addressee(s) and contain confidential and/or privileged information.
> If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately notify the sender and then delete this message and any attachments from your system. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Unauthorized disclosure and/or use of information contained in this email message may result in civil and criminal liability. “
> This e-mail has legal value according to the applicable laws only if it is digitally signed by the sender
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid doesn't reload webpage like other clients do

AndreiZeeGiant
You do realize that there's nothing "weird" about p0f, right? Perhaps you should have a read over:



On Mon, Oct 30, 2017 at 11:22 AM, Alex Rousskov <[hidden email]> wrote:
On 10/30/2017 03:51 AM, Troiano Alessio wrote:

> I've squid 3.5.20 running on RHEL 7.4. I have a problem to access
> some websites, for example www.nato.int. This website apply an
> Anti-DDoS system that reset the first connection after the TCP 3-way
> handshake (SYN/SYN-ACK/ACK/RST-ACK). All subsequent TCP connections
> are accepted. The website administrator say's it is by design.


> When I browse the site with squid proxy the browser receive an "Empty
> Response" squid error page (HTTP error code 502 Bad Gateway) and
> doesn't do the automatic retry:

This is by design as well :-).

We can change Squid behavior to retry connection resets, but I am sure
that some folks will not like the new behavior because in _their_ use
cases a retry is wasteful and/or painful. IMHO, the new behavior should
be controlled by a configuration directive, possibly an ACL-driven one.

Quality patches implementing the above feature should be welcomed IMO.
The tip of the relevant code is probably in ERR_ZERO_SIZE_OBJECT
handling inside FwdState::fail(). There is a similar code that handles
persistent connection races there already, but the zero-size reply code
may need a new dedicated FwdState flag to prevent infinite retry loops
when the origin server is broken (a much more typical use case than the
weird attempt at DDoS mitigation that you have described above).

https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F


HTH,

Alex.



> [root@soc-pe-nagios01 ~]# wget www.nato.int -e use_proxy=yes -e http_proxy=172.31.1.67:8080
> --2017-10-30 10:41:09--  http://www.nato.int/
> Connecting to 172.31.1.67:8080... connected.
> Proxy request sent, awaiting response... 502 Bad Gateway
> 2017-10-30 10:41:09 ERROR 502: Bad Gateway.
>
> I can't find an RFC that confirm if browser and proxyes should try a page reload, or if squid has an option to do that.
>
> Any help is appreciated.
>
> Best Regards, Alessio.
>
> Il presente messaggio e-mail e ogni suo allegato devono intendersi indirizzati esclusivamente al destinatario indicato e considerarsi dal contenuto strettamente riservato e confidenziale. Se non siete l'effettivo destinatario o avete ricevuto il messaggio e-mail per errore, siete pregati di avvertire immediatamente il mittente e di cancellare il suddetto messaggio e ogni suo allegato dal vostro sistema informatico. Qualsiasi utilizzo, diffusione, copia o archiviazione del presente messaggio da parte di chi non ne è il destinatario è strettamente proibito e può dar luogo a responsabilità di carattere civile e penale punibili ai sensi di legge.
> Questa e-mail ha valore legale solo se firmata digitalmente ai sensi della normativa vigente.
>
> The contents of this email message and any attachments are intended solely for the addressee(s) and contain confidential and/or privileged information.
> If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately notify the sender and then delete this message and any attachments from your system. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Unauthorized disclosure and/or use of information contained in this email message may result in civil and criminal liability. “
> This e-mail has legal value according to the applicable laws only if it is digitally signed by the sender
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid doesn't reload webpage like other clients do

Alex Rousskov
On 10/30/2017 12:15 PM, Andrei wrote:
> You do realize that there's nothing "weird" about p0f, right?

Right. I do not know why you had to ask though: There is nothing related
to p0f (i.e., a passive traffic analysis tool) in my response. And the
original question is probably unrelated to p0f as well since active
connection resets are incompatible with the idea of passive analysis.

Alex.



> On Mon, Oct 30, 2017 at 11:22 AM, Alex Rousskov wrote:
>
>     On 10/30/2017 03:51 AM, Troiano Alessio wrote:
>
>     > I've squid 3.5.20 running on RHEL 7.4. I have a problem to access
>     > some websites, for example www.nato.int <http://www.nato.int>. This website apply an
>     > Anti-DDoS system that reset the first connection after the TCP 3-way
>     > handshake (SYN/SYN-ACK/ACK/RST-ACK). All subsequent TCP connections
>     > are accepted. The website administrator say's it is by design.
>
>
>     > When I browse the site with squid proxy the browser receive an "Empty
>     > Response" squid error page (HTTP error code 502 Bad Gateway) and
>     > doesn't do the automatic retry:
>
>     This is by design as well :-).
>
>     We can change Squid behavior to retry connection resets, but I am sure
>     that some folks will not like the new behavior because in _their_ use
>     cases a retry is wasteful and/or painful. IMHO, the new behavior should
>     be controlled by a configuration directive, possibly an ACL-driven one.
>
>     Quality patches implementing the above feature should be welcomed IMO.
>     The tip of the relevant code is probably in ERR_ZERO_SIZE_OBJECT
>     handling inside FwdState::fail(). There is a similar code that handles
>     persistent connection races there already, but the zero-size reply code
>     may need a new dedicated FwdState flag to prevent infinite retry loops
>     when the origin server is broken (a much more typical use case than the
>     weird attempt at DDoS mitigation that you have described above).
>
>     https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid doesn't reload webpage like other clients do

AndreiZeeGiant
It's regarding active fingerprinting and mitigating attacks, not just it's passive use. (Sorry for the dbl send)

On Oct 30, 2017 21:41, "Alex Rousskov" <[hidden email]> wrote:
On 10/30/2017 12:15 PM, Andrei wrote:
> You do realize that there's nothing "weird" about p0f, right?

Right. I do not know why you had to ask though: There is nothing related
to p0f (i.e., a passive traffic analysis tool) in my response. And the
original question is probably unrelated to p0f as well since active
connection resets are incompatible with the idea of passive analysis.

Alex.



> On Mon, Oct 30, 2017 at 11:22 AM, Alex Rousskov wrote:
>
>     On 10/30/2017 03:51 AM, Troiano Alessio wrote:
>
>     > I've squid 3.5.20 running on RHEL 7.4. I have a problem to access
>     > some websites, for example www.nato.int <http://www.nato.int>. This website apply an
>     > Anti-DDoS system that reset the first connection after the TCP 3-way
>     > handshake (SYN/SYN-ACK/ACK/RST-ACK). All subsequent TCP connections
>     > are accepted. The website administrator say's it is by design.
>
>
>     > When I browse the site with squid proxy the browser receive an "Empty
>     > Response" squid error page (HTTP error code 502 Bad Gateway) and
>     > doesn't do the automatic retry:
>
>     This is by design as well :-).
>
>     We can change Squid behavior to retry connection resets, but I am sure
>     that some folks will not like the new behavior because in _their_ use
>     cases a retry is wasteful and/or painful. IMHO, the new behavior should
>     be controlled by a configuration directive, possibly an ACL-driven one.
>
>     Quality patches implementing the above feature should be welcomed IMO.
>     The tip of the relevant code is probably in ERR_ZERO_SIZE_OBJECT
>     handling inside FwdState::fail(). There is a similar code that handles
>     persistent connection races there already, but the zero-size reply code
>     may need a new dedicated FwdState flag to prevent infinite retry loops
>     when the origin server is broken (a much more typical use case than the
>     weird attempt at DDoS mitigation that you have described above).
>
>     https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

R: Squid doesn't reload webpage like other clients do

Troiano Alessio
In reply to this post by Troiano Alessio
Thank you Alex.
Can't be an idea to "forward" the rst to the client? In this way the proxy will be totally transparent and the reload is demanded to the client (browser).

Alessio


Il presente messaggio e-mail e ogni suo allegato devono intendersi indirizzati esclusivamente al destinatario indicato e considerarsi dal contenuto strettamente riservato e confidenziale. Se non siete l'effettivo destinatario o avete ricevuto il messaggio e-mail per errore, siete pregati di avvertire immediatamente il mittente e di cancellare il suddetto messaggio e ogni suo allegato dal vostro sistema informatico. Qualsiasi utilizzo, diffusione, copia o archiviazione del presente messaggio da parte di chi non ne è il destinatario è strettamente proibito e può dar luogo a responsabilità di carattere civile e penale punibili ai sensi di legge.
Questa e-mail ha valore legale solo se firmata digitalmente ai sensi della normativa vigente.

The contents of this email message and any attachments are intended solely for the addressee(s) and contain confidential and/or privileged information.
If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately notify the sender and then delete this message and any attachments from your system. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Unauthorized disclosure and/or use of information contained in this email message may result in civil and criminal liability. “
This e-mail has legal value according to the applicable laws only if it is digitally signed by the sender
-----Messaggio originale-----
Da: Alex Rousskov [mailto:[hidden email]]
Inviato: lunedì 30 ottobre 2017 17:22
A: Troiano Alessio <[hidden email]>; [hidden email]
Oggetto: Re: [squid-users] Squid doesn't reload webpage like other clients do

On 10/30/2017 03:51 AM, Troiano Alessio wrote:

> I've squid 3.5.20 running on RHEL 7.4. I have a problem to access some
> websites, for example www.nato.int. This website apply an Anti-DDoS
> system that reset the first connection after the TCP 3-way handshake
> (SYN/SYN-ACK/ACK/RST-ACK). All subsequent TCP connections are
> accepted. The website administrator say's it is by design.


> When I browse the site with squid proxy the browser receive an "Empty
> Response" squid error page (HTTP error code 502 Bad Gateway) and
> doesn't do the automatic retry:

This is by design as well :-).

We can change Squid behavior to retry connection resets, but I am sure that some folks will not like the new behavior because in _their_ use cases a retry is wasteful and/or painful. IMHO, the new behavior should be controlled by a configuration directive, possibly an ACL-driven one.

Quality patches implementing the above feature should be welcomed IMO.
The tip of the relevant code is probably in ERR_ZERO_SIZE_OBJECT handling inside FwdState::fail(). There is a similar code that handles persistent connection races there already, but the zero-size reply code may need a new dedicated FwdState flag to prevent infinite retry loops when the origin server is broken (a much more typical use case than the weird attempt at DDoS mitigation that you have described above).

https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid doesn't reload webpage like other clients do

Amos Jeffries
Administrator
In reply to this post by Alex Rousskov
On 31/10/17 05:22, Alex Rousskov wrote:

> On 10/30/2017 03:51 AM, Troiano Alessio wrote:
>
>> I've squid 3.5.20 running on RHEL 7.4. I have a problem to access
>> some websites, for example www.nato.int. This website apply an
>> Anti-DDoS system that reset the first connection after the TCP 3-way
>> handshake (SYN/SYN-ACK/ACK/RST-ACK). All subsequent TCP connections
>> are accepted. The website administrator say's it is by design.
>
>
>> When I browse the site with squid proxy the browser receive an "Empty
>> Response" squid error page (HTTP error code 502 Bad Gateway) and
>> doesn't do the automatic retry:
>
> This is by design as well :-).
>
> We can change Squid behavior to retry connection resets, but I am sure
> that some folks will not like the new behavior because in _their_ use
> cases a retry is wasteful and/or painful. IMHO, the new behavior should
> be controlled by a configuration directive, possibly an ACL-driven one.
> > Quality patches implementing the above feature should be welcomed IMO.
> The tip of the relevant code is probably in ERR_ZERO_SIZE_OBJECT
> handling inside FwdState::fail(). There is a similar code that handles
> persistent connection races there already, but the zero-size reply code
> may need a new dedicated FwdState flag to prevent infinite retry loops
> when the origin server is broken (a much more typical use case than the
> weird attempt at DDoS mitigation that you have described above).
>
> https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F
>
>
> HTH,
>
> Alex.
>
>
>
>> [root@soc-pe-nagios01 ~]# wget www.nato.int -e use_proxy=yes -e http_proxy=172.31.1.67:8080
>> --2017-10-30 10:41:09--  http://www.nato.int/
>> Connecting to 172.31.1.67:8080... connected.
>> Proxy request sent, awaiting response... 502 Bad Gateway
>> 2017-10-30 10:41:09 ERROR 502: Bad Gateway.
>>
>> I can't find an RFC that confirm if browser and proxyes should try a page reload, or if squid has an option to do that.

FWIW: what Squid is seeing is that the TCP is *successful*, then the
HTTP request delivery gets a TCP RST. This is indistinguishable from the
many broken IP/VPN tunnel, path-MTU and NAT errors that occur all over
the Internet on a regular basis.


That operational state (HTTP underway) also means RFC 7230 is the
relevant place to look for behaviour requirements. Section 6.3.1 says:

Browsers requirement:
"
   a client MAY open a
    new connection and automatically retransmit an aborted sequence of
    requests if all of those requests have idempotent methods (Section
    4.2.2 of [RFC7231]).
"

Squid requirement:
"
   A proxy MUST NOT automatically retry non-idempotent requests.
"

So it depends entirely on what type of HTTP request was being performed.
If it was CONNECT, POST or similar then retry is forbidden.

Squid should already be re-trying for GET requests and similar. If it is
not then that can be treated as a bug. Alex already pointed out the code
place to look at for retry handling. The 'Method' class in Squid
provides an isIdempotent() accessor that can be used to check whether
the request is retriable or not.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: R: Squid doesn't reload webpage like other clients do

Amos Jeffries
Administrator
In reply to this post by Troiano Alessio
On 31/10/17 21:29, Troiano Alessio wrote:
> Thank you Alex.
> Can't be an idea to "forward" the rst to the client? In this way the proxy will be totally transparent and the reload is demanded to the client (browser).
>
> Alessio
>

That one is already on the wishlist and even has a old patch that seems
never to have received the final steps for submission:
<https://bugs.squid-cache.org/show_bug.cgi?id=2042>

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: R: Squid doesn't reload webpage like other clients do

Alex Rousskov
On 10/31/2017 02:53 AM, Amos Jeffries wrote:
> On 31/10/17 21:29, Troiano Alessio wrote:
>> Can't be an idea to "forward" the rst to the client? In this way the
>> proxy will be totally transparent and the reload is demanded to the
>> client (browser).

> That one is already on the wishlist and even has a old patch

... but the patch claims to have no affect on cases where Squid responds
with an error page. That choice made it possible for that implementation
to be configuration-free.

If Squid starts forwarding *all* connection resets to clients, then some
admins will rightfully complain that their users deserve a nice
proxy-generated error page with a support ticket submission interface
(instead of a silent connection reset with a confusing browser error page).

In summary, no single behavior will satisfy everybody. We need a new
configuration option flexible enough to cover known use cases, including
Alessio's. For example, on_server_error with "retry", "respond", and
"terminate" actions (ideally with an ACL to detect cases where there are
no unused peer addresses left to try and an ACL to count the number of
retries for the current peer address).

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid doesn't reload webpage like other clients do

Alex Rousskov
In reply to this post by Amos Jeffries
On 10/31/2017 02:51 AM, Amos Jeffries wrote:
> That operational state (HTTP underway) also means RFC 7230 is the
> relevant place to look for behaviour requirements. Section 6.3.1 says:

>   A proxy MUST NOT automatically retry non-idempotent requests.

> So it depends entirely on what type of HTTP request was being performed.

Unfortunately, it is more nuanced than that. The RFC section you are
quoting lives inside the "6.3. Persistence" section about persistent
connections. It also talks about retransmitting a "sequence of
requests", further implying connection persistency scope. The old RFC
2616 even gave a very pconn-specific example as the rationale.

Squid implementation assumes that all those requirements apply to
persistent connection race conditions and only to those conditions.
Whether that is what RFC authors wanted is not clear to me. It would be
nice to clarify that with the HTTP WG. Any volunteers?

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid doesn't reload webpage like other clients do

Amos Jeffries
Administrator
On 01/11/17 05:53, Alex Rousskov wrote:

> On 10/31/2017 02:51 AM, Amos Jeffries wrote:
>> That operational state (HTTP underway) also means RFC 7230 is the
>> relevant place to look for behaviour requirements. Section 6.3.1 says:
>
>>    A proxy MUST NOT automatically retry non-idempotent requests.
>
>> So it depends entirely on what type of HTTP request was being performed.
>
> Unfortunately, it is more nuanced than that. The RFC section you are
> quoting lives inside the "6.3. Persistence" section about persistent
> connections. It also talks about retransmitting a "sequence of
> requests", further implying connection persistency scope. The old RFC
> 2616 even gave a very pconn-specific example as the rationale.
>
> Squid implementation assumes that all those requirements apply to
> persistent connection race conditions and only to those conditions.
> Whether that is what RFC authors wanted is not clear to me. It would be
> nice to clarify that with the HTTP WG. Any volunteers?
>
> Alex.
>

As the first line of that section says:
"
    HTTP/1.1 defaults to the use of "persistent connections"
"

So IMO it is reasonable to assume that the HTTP/1.1 portion of the
traffic is always scoped as 'persistent'. Most of the section(s) are
about issues later in the connection traffic, but those specific
statements might be applied before the first transaction is complete.

The question seems to be more about whether we scope the period between
SYN+ACK and first data bytes arriving to be governed by TCP or HTTP/1.1
protocol. The HTTP side has at least those statements I referenced for
better interoperable behaviour than currently coded.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users