Vgutierrez added a comment.
Probably HSTS is only being implemented by browsers.
There is any particular reason to target the HTTP version or it could be
bumped to HTTPS? Considering that we don't serve traffic over port 80 besides
than 301s for GET/HEAD requests and 403s for PUT/POST ones
Vgutierrez added a comment.
In T330906#8657917 <https://phabricator.wikimedia.org/T330906#8657917>,
@Ennomeijers wrote:
> Thanks for the replies! Advising to use HTTPS over HTTP makes sense.
>
> But not supporting redirection from HTTP to HTTPS will in my opi
Vgutierrez added a comment.
last BAD_INCOMING_RESPONSE error on cp1075 was a few seconds before deploying
this:
20191122.15h16m44s CONNECT:[0] could not connect [BAD_INCOMING_RESPONSE] to
10.2.2.1 for
'https://appservers-rw.discovery.wmnet/wiki/Q76150152?action=constraintsrdf
Vgutierrez added a parent task: T236988: ats-be on the text cluster is
experiencing broken connections.
TASK DETAIL
https://phabricator.wikimedia.org/T237319
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Vgutierrez
Cc: darthmon_wmde, elukey
Vgutierrez added a comment.
And I can reproduce the issue as well with
docker-registry.wikimedia.org/dev/stretch-php72-fpm-apache2.
Dockerfile:
FROM docker-registry.wikimedia.org/dev/stretch-php72-fpm-apache2
RUN mkdir -p /tmp/php
RUN sed -i s/runuser/www-data/ /etc/apache2
Vgutierrez added a comment.
And using a dumb TCP client we can see the 4 excess bytes:
vgutierrez@mwdebug2001:~$ python3
[...]
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('10.192.0.98',
Vgutierrez added a comment.
please note that I cannot reproduce on mwdebug using `curl -i`, see the
difference:
vgutierrez@mwdebug2001:~$ curl --resolve en.wikipedia.org:80:10.192.0.98
http://en.wikipedia.org/w/vgutierrez.php -v
* Added en.wikipedia.org:80:10.192.0.98 to DNS cache
Vgutierrez added a comment.
so it looks like the apache fix doesn't fix every scenario. This small PoC
triggers the issue:
https://phabricator.wikimedia.org/T237319
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Vgutierrez
Cc: Addshore
Vgutierrez added a comment.
nope, a 5xx doesn't translate to `BAD_INCOMING_RESPONSE`, actually is
specifically whitelisted:
case STATUS_CODE_SERVER_ERROR:
TxnDebug("http_trans", "[is_response_valid] Response Error: Origin
Server returned 500 - allowing");
Vgutierrez added a comment.
I find this pretty worrisome for the following reasons:
1. right now we have one remap rule that catches all the requests handled by
appservers-rw. This means that ATS only tracks one counter of server connection
retries for all the sites handled
Vgutierrez added a comment.
From ATS source code, it looks like ATS logs connect errors on the first
attempt but it's configured to perform 3 attempts, so a log line indicating a
connection error isn't the same as a 502 iff the request is retryable
Vgutierrez added a comment.
I don't think so, at 00:25 GMT we had 75 requests (including yours) failing
against appservers-rw.discovery.wmnet from ats-be@cp4030:
vgutierrez@cp4030:/var/log/trafficserver$ fgrep 20191120.00h25m error.log
|fgrep appservers-rw.discovery.wmnet |wc -l
Vgutierrez added subscribers: ema, Vgutierrez.
Vgutierrez added a comment.
For `2019-11-14 18:33:15 GMT`, ats-be in cp4030 is reporting
`20191114.18h33m15s CONNECT: could not connect to 10.2.2.1 for
'https://appservers-rw.discovery.wmnet/wiki/Special:PageTranslation' (setting
last failure
Vgutierrez added a comment.
that's right, operations/dns manages wikiba.se
TASK DETAIL
https://phabricator.wikimedia.org/T155359
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Dzahn, Vgutierrez
Cc: MasinAlDujailiWMDE, Vgutierrez, Krenair
Vgutierrez claimed this task.
Vgutierrez closed this task as "Resolved".
Vgutierrez added a comment.
Fixed by T193408 <https://phabricator.wikimedia.org/T193408>
TASK DETAIL
https://phabricator.wikimedia.org/T210134
EMAIL PREFERENCES
https://phabricator.wikimedia.or
Vgutierrez raised the priority of this task from "Lowest" to "High".Vgutierrez assigned this task to Keegan.Vgutierrez removed subscribers: Vgutierrez, 238482n375.Vgutierrez removed projects: HAWelcome, HHVM, Language-2018-Jan-Mar, Language-2018-Apr-June, Ladies-That-FOSS-Media
Vgutierrez removed a project: Security.Vgutierrez changed the visibility from "Custom Policy" to "Public (No Login Required)".
TASK DETAILhttps://phabricator.wikimedia.org/T184386EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Vgut
Vgutierrez removed subscribers: Vgutierrez, 238482n375.Vgutierrez removed a project: Security.Vgutierrez changed the visibility from "Custom Policy" to "Public (No Login Required)".
TASK DETAILhttps://phabricator.wikimedia.org/T184419EMAIL PREFERENCEShttps://phabricator.wi
Vgutierrez removed a project: Security.Vgutierrez changed the visibility from "Custom Policy" to "Public (No Login Required)".
TASK DETAILhttps://phabricator.wikimedia.org/T184537EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferen
Vgutierrez removed a subscriber: 238482n375.Vgutierrez removed a project: Security.
TASK DETAILhttps://phabricator.wikimedia.org/T184434EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: fgiunchedi, VgutierrezCc: fgiunchedi, gerritbot, MoritzMuehlenhoff
Vgutierrez raised the priority of this task from "Lowest" to "Normal".Vgutierrez assigned this task to fgiunchedi.Vgutierrez removed projects: HAWelcome, HHVM, Language-2018-Jan-Mar, Language-2018-Apr-June, Ladies-That-FOSS-MediaWiki, LabsDB-Auditor, Hashtags, Data-releas
21 matches
Mail list logo
