Re: [Tools-discuss] Why does xml2rfc download over HTTP?

[Henrik Levkowetz <[e-mail]>]

Hi,

On 2019-02-02 14:37, Carsten Bormann wrote:
> Right. However, who ever fixes this should keep in mind that software
> installed on a laptop does not always have access to a good set of
> root certificates (the browser is likely to, but Python software may
> not have access to the browser set), so it would be useful to have an
> escape hatch of some kind (preferably through environment variables,
> so complex Makefiles don’t have to be touched).
> 
> Maybe adding a little bit of robustness to the download process
> (e.g., don’t cache it if it isn’t valid XML) would also help.

Yes, that makes sense.  Added in my sources, will be part of the next
release.

Thanks, and best regards,

	Henrik

> 
> Grüße, Carsten
> 
> 
>> On Feb 1, 2019, at 23:40, Richard Barnes <[e-mail]> wrote:
>> 
>> In particular, this seems to be the patch necessary to resolve the issue:
>> 
>> Index: trunk/cli/xml2rfc/parser.py
>> ===================================================================
>> --- trunk/cli/xml2rfc/parser.py	(revision 2965)
>> +++ trunk/cli/xml2rfc/parser.py	(working copy)
>> @@ -53,8 +53,6 @@
>>                   no_network=None, network_locs= [
>>                       'https://xml2rfc.ietf.org/public/rfc/',
>>                       'https://xml2rfc.tools.ietf.org/public/rfc/',
>> -                     'http://xml2rfc.ietf.org/public/rfc/',
>> -                     'http://xml2rfc.tools.ietf.org/public/rfc/',
>>                   ],
>>                   rfc_number=None, options=base.default_options):
>>          self.quiet = quiet if quiet != None else options.quiet
>> 
>> On Fri, Feb 1, 2019 at 5:08 PM Eric Rescorla <[e-mail]> wrote:
>> Hi folks,
>> 
>> I recently went to build a draft and got a pile of errors about how the references didn't parse. Digging into things a bit, I discovered that the reference was the page from a captive portal on one of my flights. I'm not sure how this happened, but looking at xml2rfc, it appears that it tries HTTPS URIs and then HTTP URIs, which seems like it's going to have the wrong outcome in the situation where the captive portal blocks HTTPS and intercepts HTTP.
>> 
>> Is there a good reason to continue to allow HTTP URIs in the tool?
>> 
>> -Ekr
>> 
>> 
>> 
>> 
>> ___________________________________________________________
>> Tools-discuss mailing list
>> [e-mail]
>> 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 [e-mail]
>> 
>> Please report tools.ietf.org bugs at
>> http://tools.ietf.org/tools/issues
>> or send email to [e-mail]
>> ___________________________________________________________
>> Tools-discuss mailing list
>> [e-mail]
>> 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 [e-mail]
>> 
>> Please report tools.ietf.org bugs at
>> http://tools.ietf.org/tools/issues
>> or send email to [e-mail]
> 
> ___________________________________________________________
> Tools-discuss mailing list
> [e-mail]
> 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 [e-mail]
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [e-mail]
>