Subject: [Tools-discuss] xml2rfc.ietf.org unavailable

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Jun 2019 12:24:59 -0400

when running xml2rfc, it reaches out to

raise RemoteDisconnected("Remote end closed connection without"
urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))

I thought that this had been put behind cloudflare, and was no longer a
"tools" item, but I've learnt that was not the case (yet?)

If I wait a bit, it usually resolves itself.

Running it now, tracing to be sure of the URL which is failing, for some
reason, this time it is happy with the files which were cached. (Heisenbug)

Given that this is all static content, it seems like we should be able
to have it more widely available under the same URL.

BTW: I noticed strac'ing that it actually tries to load the URL as a file:
  stat("https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml", 0x7ffed1b5a650) = -1 ENOENT (No such file or directory)

I guess, because the prefix might be a path.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 3 Jun 2019 21:49:18 +0200

Maybe I have said that before, but I seem to have better experiences with getting bibxml from xml2rfc.tools.ietf.org over xml2rfc.ietf.org.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Jun 2019 18:14:25 -0400

Carsten Bormann <[email-masked]> wrote:
    > Maybe I have said that before, but I seem to have better experiences
    > with getting bibxml from xml2rfc.tools.ietf.org over xml2rfc.ietf.org.

Oh. I was going to say that they are now aliases for each other, but they are
not.   xml2rfc.ietf.org is on cloudflare.

my xml2rfc was 2.9.6 (on my desktop), and it is now 2.22.3 after upgrade.
So maybe I'll talk to a different URL by default now.
(I could go look into the source, but this way, it's much more adventurous...)

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 4 Jun 2019 13:03:50 +0200

> not.   xml2rfc.ietf.org is on cloudflare.

Oh, bother!  _That_ must be the reason why the redirects fail regularly
recently.  I'll have the secretariat change that.

	Henrik

> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 4 Jun 2019 13:14:38 +0200

Hi Michael,

> recently.  I'll have the secretariat change that.

Looking into this some more, I _don't_ find that xml2rfc.ietf.org is
served by cloudflare, as far as I can tell here:

  $ host xml2rfc.ietf.org
  xml2rfc.ietf.org is an alias for ietf.org.
  ietf.org has address 4.31.198.44
  ietf.org has IPv6 address 2001:1900:3001:11::2c
  ietf.org mail is handled by 0 mail.ietf.org.

Compare that to www.ietf.org:

  $ host www.ietf.org
  www.ietf.org is an alias for www.ietf.org.cdn.cloudflare.net.
  www.ietf.org.cdn.cloudflare.net has address 104.20.1.85
  www.ietf.org.cdn.cloudflare.net has address 104.20.0.85
  www.ietf.org.cdn.cloudflare.net has IPv6 address 2606:4700:10::6814:155
  www.ietf.org.cdn.cloudflare.net has IPv6 address 2606:4700:10::6814:55

Could you provide more details on what makes you believe xml2rfc.ietf.org
is served by cloudflare?

	Henrik

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Jun 2019 10:46:02 -0400

> Could you provide more details on what makes you believe xml2rfc.ietf.org

ignorance!!!
I assumed that "ietf.org" was now always pointing at cloudflare, not
realizing that www.ief.org pointed at that longer name.

I also noticed that xml2rfc.tools.ietf.org and xml2rfc.ietf.org were not
pointing at the same IP, although I now notice they are on the same subnet,
so probably the same host.

Given that it's all relatively static content, is there a reason cloudflare
couldn't be invoked for the reference.* files?   I know that the online
xml2rfc utility is at xml2rfc.*, so I'd be happy to have another hostname
for the reference files.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 4 Jun 2019 18:46:52 +0200

Hi Michael,

> so probably the same host.

No, one is the official ietf.org server, the other is one of the tools.ietf.org
servers.

> couldn't be invoked for the reference.* files?

Cloudflare won't cache indefinitely, and if the redirect is not in cache,
you might see exactly the problem we've been seing lately.  Serving the
redirects isn't heavy on the server.  For the tools servers, there are
other complications, one being that it's a delegated domain, so would
possibly need a new cloudflare contract.  See also below WRT a rewrite.

The reason the actual content isn't available on the main IETF server, and
served through cloudflare, is that it's still being generated by legacy TCL
code inherited from Marshall Rose.  Getting that running in the first place
involved ferreting out old libs from various places, and I've just not had
the energy to organize all of that (through the AMS ops staff) for the main
server.  Additionally, I think it's really time for a rewrite.

That said, the failures to redirect properly started fairly recently, and
I'd like to sort that out -- there's no reason to have that issue.

> I know that the online

Given the pain we had when transitioning from the repositories being served
from xml.resource.org to xml2rfc.tools.ietf.org, I would not seriously
consider another hostname.  There are too many files out there being copied
and re-used which assume one of the current 2 names (xml2rfc.ietf.org or the
equivalent tools domain).

Best regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 5 Jun 2019 07:48:44 +0200

On 03.06.2019 21:49, Carsten Bormann wrote:
> ...

Yes, as there's a 302 redirect.

FWIW, it would be helpful if it was a 301 instead - some caches might be
smart enough to take advantage of that.

Best regards, Julian