URLField should allow scheme to be empty

[SteveB]

How to avoid those browser warnings about mixing secure and insecure content on a web page?

Wouldn't it be great to be able to specify a URL for a resource (be it a script, image, iframe etc.)  such that if the current page is insecure (using a http:// scheme) the content would be fetched using the same scheme?

And when the current page is secure (using a https:// scheme) the resource would also be fetched as if it had a https scheme?

Well you can, just leave out the scheme in the URL. That is, specify it as "//example.com/some/path/" and the browser will apply the same scheme as the parent page.

Great! - But, it is not possible to specify a URL such as this in a Django URLField. Thanks to https://code.djangoproject.com/ticket/5331, a blank scheme will be cause the field verification to insert "http" as the scheme, and you lose the flexibility described above.

It is currently not possible (in Django 1.5.1) to get a URLField validating with a blank scheme, so the ability to specify a URL for a resource which can be follow the scheme of the parent page is not possible.

I content that the 5331 ticket may not have taken into account the flexibility which the empty scheme offers on web pages, and I urge that it be reconsidered.

What do folks think?

SB

[Juan Pablo Martínez]

I love it.
If URLField has an option like "scheme_required=False" or something like that.
No behaviour is the "correct", append or not append scheme. The option to our needs seems to be more correct.

Regards,

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
juanpex

[Alex Ogier]

Don't add an option, it's not needed. URLs with blank schemas are valid, it's just a bug that Django adds 'http://' in that case. So make a ticket, +1 from me.

Best,

Alex Ogier

[Atul Bhouraskar]

As per RFC 3986 (see section 4, in particular 4.2) all of the following are valid:

Absolute URI 

http://www.example.com/images/xyz.png

Network path reference 
//www.example.com/images/xyz.png

Suffix reference (frowned upon but valid?) 
www.example.com/images/xyz.png

Absolute path reference 
/images/xyz.png

Relative path references 
images/xyz.png
../images/xyz.png

Should URLField allow all of them? Or do we need options to selectively allow/disallow URL components? Or maybe have AbsoluteURLField, NetworkPathURLField etc?

Only an absolute URI is *always* relevant. Network path references (and relative path references) are only relevant in the context of a web page loaded in a browser (e.g. a URL to be rendered within the context of an email only makes sense if absolute).

In any case (in my opinion) the URLField should not automatically add a missing http: - it should either reject the contents or allow it as per documented rules.

Atul

[Alex Ogier]

After poking around a bit[1], it appears that URLFields are used almost exclusively for canonical links to webpages, and are not typically used as, say, the target of internal redirects, or resources that are loaded on a page. In addition, it looks like the code from ticket 5331 that automatically adds 'http://' that I referred to as a bug in Django was long ago reverted[2]. So it seems counterproductive to do anything to disrupt the current expectations of URLField users, which is that the field is an absolute URL with scheme, host, the whole shebang. So I change my previous +1 to a -1. If you want to have a field that allows relative or scheme-relative URLs, creating your own field is the way to go.

Best,

Alex Ogier

[1]: https://github.com/search?q=language%3Apython+URLField&ref=commandbar&type=Code

[2]: https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L1323