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 On Wed, Apr 3, 2013 at 7:38 PM, Atul Bhouraskar <[email protected]>wrote: > 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 > > > On 4 April 2013 07:26, Alex Ogier <[email protected]> wrote: > >> 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 >> >> >> On Wed, Apr 3, 2013 at 4:24 PM, Juan Pablo MartÃnez <[email protected]>wrote: >> >>> 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, >>> >>> >>> On Wed, Apr 3, 2013 at 5:14 PM, SteveB <[email protected]> wrote: >>> >>>> 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 >>>> >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected] >>>> . >>>> 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 >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
