On Sat, Mar 16, 2013 at 3:15 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 15 Mar 2013 16:16, Carl Meyer c...@oddbird.net wrote:
tl;dr: I see your points, we'll change the PEP to allow clients to use
hostnames instead of the rel attributes if they prefer.
I will veto any such change.
On Mon, Mar 18, 2013 at 1:22 PM, PJ Eby p...@telecommunity.com wrote:
Actually, setuptools trusts redirects, so that mechanism is available
for splitting the hosted files to another domain.
As it stands, though, I don't see a way to support this without
introducing confusion.
Oops - that
On Mar 18, 2013, at 3:02 PM, Richard Jones rich...@python.org wrote:
Some suggested edits; I'm otherwise quite happy with the current draft.
On 15 March 2013 02:29, holger krekel hol...@merlinux.eu wrote:
History and motivations for external hosting
Could we please have a reference to
On 03/18/2013 10:22 AM, PJ Eby wrote:
Actually, setuptools trusts redirects, so that mechanism is available
for splitting the hosted files to another domain.
By trusts redirects you mean that redirects bypass allow-hosts? This
seems to contradict your line of argument up to this point (that
Hi Richard,
On 03/18/2013 12:02 PM, Richard Jones wrote:
Some suggested edits; I'm otherwise quite happy with the current draft.
On 15 March 2013 02:29, holger krekel hol...@merlinux.eu wrote:
History and motivations for external hosting
Could we please have a reference to the Package
On 03/16/2013 12:15 AM, Nick Coghlan wrote:
On 15 Mar 2013 16:16, Carl Meyer c...@oddbird.net
mailto:c...@oddbird.net wrote:
tl;dr: I see your points, we'll change the PEP to allow clients to use
hostnames instead of the rel attributes if they prefer.
I will veto any such change. Clients
Hi all, in particular Philip, Marc-Andre, Donald,
Carl and me decided to simplify the PEP and avoid the somewhat
awkward ``simple/-with-externals`` index for various reasons, among them
Marc-Andre's criticisms. This also means present-day installation tools
(shipped with Redhat/Debian/etc.) will
Do we even need the internal/external rel info? I was planning to
just use the URL hostname.
i.e., are there any use cases for designating an externally-hosted
file internal, or an internally-hosted file external? If not, it
seems the rel= is redundant.
It's also more work to implement, vs.
On Mar 15, 2013, at 11:15 AM, PJ Eby p...@telecommunity.com wrote:
Do we even need the internal/external rel info? I was planning to
just use the URL hostname.
i.e., are there any use cases for designating an externally-hosted
file internal, or an internally-hosted file external? If not,
On Fri, Mar 15, 2013 at 11:15 -0400, PJ Eby wrote:
Do we even need the internal/external rel info? I was planning to
just use the URL hostname.
i.e., are there any use cases for designating an externally-hosted
file internal, or an internally-hosted file external? If not, it
seems the
On 03/15/2013 09:15 AM, PJ Eby wrote:
Do we even need the internal/external rel info? I was planning to
just use the URL hostname.
i.e., are there any use cases for designating an externally-hosted
file internal, or an internally-hosted file external? If not, it
seems the rel= is
On Fri, Mar 15, 2013 at 12:07 PM, Carl Meyer c...@oddbird.net wrote:
On 03/15/2013 09:15 AM, PJ Eby wrote:
Do we even need the internal/external rel info? I was planning to
just use the URL hostname.
i.e., are there any use cases for designating an externally-hosted
file internal, or an
On Mar 15, 2013, at 12:51 PM, PJ Eby p...@telecommunity.com wrote:
On Fri, Mar 15, 2013 at 12:07 PM, Carl Meyer c...@oddbird.net wrote:
On 03/15/2013 09:15 AM, PJ Eby wrote:
Do we even need the internal/external rel info? I was planning to
just use the URL hostname.
i.e., are there any
On 03/15/2013 10:51 AM, PJ Eby wrote:
Giving a blanket pass to all external links doesn't seem like
such a good idea to me,
This is a very good point, and it should be made clearer in the PEP that
we don't recommend a single blanket option to allow all external links,
but an option (like
Thanks, Holger. This version looks a lot better :-)
There are still some minor quirks which would need to be
addressed more explicitly, but overall, this proposal provides
a good way forward.
Perhaps it would also be possible to add the secured download
links and the caching/proxying ideas to
On Fri, Mar 15, 2013 at 1:39 PM, Carl Meyer c...@oddbird.net wrote:
up to you whether you also want to use rel=internal as a hint for
implicitly (perhaps with warning) adding to --allow-hosts,
That's the bit I don't like. The security model is that if it's not
allowed by allowed-hosts, it's
A little off-topic, but I thought you might enjoy this in the
context of all the crypto, hash and signing debate:
http://xkcd.com/1181/
Cheers,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 15 2013)
Python Projects, Consulting and Support ...
tl;dr: I see your points, we'll change the PEP to allow clients to use
hostnames instead of the rel attributes if they prefer. More comments below:
On 03/15/2013 12:59 PM, PJ Eby wrote:
That's the bit I don't like. The security model is that if it's not
allowed by allowed-hosts, it's *not
On Fri, Mar 15, 2013 at 7:16 PM, Carl Meyer c...@oddbird.net wrote:
Ok, pending agreement from Holger I'll make a change in the PEP to
explicitly allow clients to make decisions based on either the rel
attributes or based on hostnames. Would that be sufficient to address
your concerns?
Yes.
On Fri, Mar 15, 2013 at 22:01 -0400, PJ Eby wrote:
On Fri, Mar 15, 2013 at 7:16 PM, Carl Meyer c...@oddbird.net wrote:
Ok, pending agreement from Holger I'll make a change in the PEP to
explicitly allow clients to make decisions based on either the rel
attributes or based on hostnames.
20 matches
Mail list logo
