>> Then maybe web server is the best option. In all cases you have to
>> configure something until someday 'runserver' come with ssl support.
I think that no one would really object if runserver was SSL-aware,
however people requesting it need to be aware that having an SSL-aware
webserver is significantly more difficult that having a simple HTTP
web server. The things that come to mind are:
- extra dependencies: I'm not sure about all of those, but at least
openssl comes to mind
- the need to have a server certificate: While not a terribly
complex task to generate one, some decisions need to be made (e.g.
where it will be stored?).
- more complex URL handling for testing. As local server uses port
8000 by default and links are usually relative, it's not a big deal.
But if people start relying on having HTTPS dev webserver, they might
get confused if that one is not running on default port 443. So, if
dev web server was running on port 8443, people would need to keep
this in mind when working on their templates / redirects.
On top of those, I can see 2 big risks:
- if SSL-aware development server exists and easily available (just
one command), people could start relying on it as it'd be much easier
to set up than any other SSL website. That would be a big mistake, the
dev server would be very insecure, missing lots of necessary features
(and almost certainly having a self-signed certificate).
- it'd probably only escalate things. If people get SSL-enabled dev
server, they start asking why it does not support client-side
certificates :)
Just my 2 cents.
Jirka
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
