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.
