Re: IO Error whenever page is named contact.html

"Michael[tm] Smith" <[email protected]> Tue, 5 May 2020 20:25:55 +0900
Newsgroups gmane.org.w3c.validator
Message-ID <[email protected]>
--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

OK, I looked into this and that short answer is that it=E2=80=99s a hosting=
 issue
with the https://www.usa-travel/ site and with a number of other sites. And
there is nothing we can do from the W3C side to fix it.

If you think this problem is affecting a site you run, what you can do is:
Tell your hosting provider to whitelist the 128.30.52.0/24 subnet. That is
the IP range for the W3C validator service.

The longer answer is that there appear to be a number of hosting providers
or sites that are running some kind of blocking mechanism which checks the
IP address of each request, and if (1) they find that the IP address is in
some IP address is in some blocklist they use, and (2) the request URL has
=E2=80=9Ccontact=E2=80=9D or =E2=80=9Cregister=E2=80=9D in the path, then t=
he mechanism causes the server
to respond with a 409 error.

The sites with this issue all seem be sites that are are running Wordpress
or in some cases maybe not running Wordpress but just running a PHP backend.

And it=E2=80=99s possible that the mechanism behind this issue is the softw=
are
system called =E2=80=9CWordfence=E2=80=9D.

Regardless, whatever the system is that=E2=80=99s doing this, it appears to=
 rely on
checking some kind of distributed blocklist of IP addresse =E2=80=94 and th=
e W3C
validator IP address range ended up in that blocklist.

So, as I mentioned above, if you think your site is affected by this, then
ask your hosting provider to un-block the 128.30.52.0/24 subnet, or ask
them to get the 128.30.52.0/24 subnet removed from whatever distributed
blocklists they=E2=80=99re using =E2=80=94 or else ask them to quit using a=
ltogether
whatever they find the 128.30.52.0/24 subnet IP addresses in.

Whatever blocklists exists that have 128.30.52.0/24 IP addresses in them
are bad, broken, poorly-administered blocklists that nobody should be
relying on. There is nothing originating from those (W3C) addresses that
even remotely could be considered abuse =E2=80=94 nothing that would merit =
those IP
addresses ending up in the blocklist.

And if W3C server IP addresses are in a blocklist mistakenly, it is very
likely that quite a few other legitimate IP addresses are mistakenly in
that same blocklist. And the effect of that would be that you have users/
customers who aren=E2=80=99t able to access any pages at your site which ha=
ve
=E2=80=9Ccontact=E2=80=9D or =E2=80=9Cregister=E2=80=9D in the page filenam=
es/paths.

Leonid Batkhan <[email protected]>, 2020-05-04 18:27 -0400:
> Archived-At: <https://www.w3.org/mid/002301d62263$46945040$d3bcf0c0$@lene=
tek.com>
>=20
> I tried validating several websites, and noticed that whenever page is
> called contact.html I am getting the following
>=20
> 1.      IO Error: HTTP resource not retrievable. The HTTP status from the
> remote server was: 409.
>=20
> https://www.usa-travel.us/contact.html
>=20
> Here is a screenshot:
>=20
>=20
>=20
> I checked that on several websites with consistent results which only
> affects pages named contact.html.  Even when I renamed perfectly validated
> page to be named contact.html that page stops being validated.
>=20
> Could you please let me know what is going on?
>=20
> Thank you in advance.
>=20
> Leonid Batkhan
>=20
> =20
>=20
> =20
>=20
>=20



--=20
Michael[tm] Smith https://people.w3.org/mike

--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE1IdYVkFeY5ZNh0RRh9F0d7w6S5UFAl6xTTsACgkQh9F0d7w6
S5Xinw//XyDILl40MJwiD4kRtue/o1SxDOj2vETrDQsEFHS9ySOwGzv7QU/rwVOM
DYXfI5dxTW4AyB/FOAGQNW8xyFw70jn3DV7iTPIcaIbtDCkChjcjj4sENdgPIUBA
SqCoAeTZueTgDrXXSEMDg4OQQsGNKVKlX86Y+xr2WSWHn41+Sl2JP1D7dALluf0z
B9Sa6OA6IFLH41oHI03zWxqDVdOvBUbLyv0y8CRA+xD+EZaTGJkXBIhnUG4WnqMC
YRoSRwhL5WuHuhGilsI51UqVu0FoEuc/cGWpZbm3ngi7ropSVgiliIE2E4fWFNnC
bE5/aAu0L8wt1RqknBzaNDeXUvi3mZQorQpnXTGMgjAiRknyitwl7ZgAa7O9y9RS
B8S1iiw8gGXHSxiQWSeUjGwMjbhtUflED6ZrkTd2lNmqajVtWb6RroczA4pbQ6bh
xzoKv8mf9XPMrAR7R4va2kMc3wp5v7v7Z7pJE8fgzCUzOfj9diXQZRLTiHM1IXac
zDzuyPvVntOf7Yv+JH4oGOLyAykjy3oDGgqZax+UH6frFOMsDXN30hJHfpnI+CYo
VYA1hVHSLpknFUVfdzLA8GWp4qVM0sWAuOGTqoDTDvihhyKuWTIhb/wMI9S3DBkd
dWf+P6ogWa2hTn9iSUqBL01h3Qb1rdLazPVzcV/RP8hUWJeq8O0=
=qyvq
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--