ConnectionResetError in test_closes_connection_without_content_length

[Zhiqiang Liu]

I run the test suits for master and get the following error.

Traceback (most recent call last):
  File 
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/case.py",
 
line 58, in testPartExecutor
yield
  File 
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/unittest/case.py",
 
line 577, in run
testMethod()
  File 
"/Users/ZachLiu/CS/Python/Projects/Django/django/django/test/utils.py", 
line 371, in inner
return func(*args, **kwargs)
  File 
"/Users/ZachLiu/CS/Python/Projects/Django/django/tests/servers/tests.py", 
line 80, in test_closes_connection_without_content_length
conn.getresponse()
  File 
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/http/client.py",
 
line 1171, in getresponse
response.begin()
  File 
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/http/client.py",
 
line 351, in begin
version, status, reason = self._read_status()
  File 
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/http/client.py",
 
line 313, in _read_status
line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File 
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/socket.py",
 
line 374, in readinto
return self._sock.recv_into(b)
ConnectionResetError: [Errno 54] Connection reset by peer

Is there anything I missed? Anyone can help?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9b97b2a3-160f-4c34-b4fd-c447cd1f6895%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ConnectionResetError in test_closes_connection_without_content_length

[Zhiqiang Liu]

>
> Yeah I believe it is a new test, so I can't test if it is working for 1.11.
>

I did get it to pass after adding except like this

 try:
conn.request('GET', '/example_view/', headers={'Connection': 
'keep-alive'})
response = conn.getresponse().read()
conn.request('GET', '/example_view/', headers={'Connection': 
'close'})
with self.assertRaises(RemoteDisconnected, msg='Server did not 
close the connection'):
try:
conn.getresponse()
except ConnectionAbortedError:
if sys.platform == 'win32':
self.skipTest('Ignore nondeterministic failure on 
Windows.')
except ConnectionResetError:
self.skipTest('Ignore failure.')

Tom because you said it varies by OS, so I am not sure which message to add 
so I just used 'Ignore failure', should I use something else? I can submit 
a simple PR for that.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5eafe681-9fa6-4bdb-a12e-433f51bcb2f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

New Feature: Allow password reset token to expire in under a day

[Zhiqiang Liu]

I need general consensus on how to proceed with supporting password expire 
time to be under a day. Currently it is not possible because we use 
PASSWORD_RESET_TIMEOUT_DAYS.

In ticket 28622  we have two 
options. 

One is to continue to use the same setting PASSWORD_RESET_TIMEOUT_DAYS, but 
change the value to non-integer (such as timedelta) so we can send hours, 
minutes, etc to it.

The other one is to create a new setting like PASSWORD_RESET_TIMEOUT which 
takes seconds.To support backward compatibility, I think we should keep 
PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
PASSWORD_RESET_TIMEOUT when provided.

I'm unsure which one is better, so inputs are welcome.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c8e96008-eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Zhiqiang Liu]

Yeah I don't think float number of days is a good choice because the 
calculation will be weird with precision issues.

I think it makes sense to use PASSWORD_RESET_TIMEOUT. For timedelta vs. 
integer seconds. Timedelta has the benefit of readability, but integer has 
the benefit of simplicity. I think in SETTINGS everything should be as 
simple as possible, so I think integer seconds is a better choice here. And 
it is used in most applications too.


On Thursday, September 21, 2017 at 8:56:36 AM UTC-4, charettes wrote:
>
> That's what I proposed on the ticket but I feel like it felt odd to me, 
> the setting name does't suggest this is possible and it might be hard to 
> achieve exact second precious because of float rounding?
>
> In my opinion introducing PASSWORD_RESET_TIMEOUT with timedelta support 
> would be the best option.
>
> Simon
>
> Le jeudi 21 septembre 2017 05:26:23 UTC-4, Adam Johnson a écrit :
>>
>> Why not just keep PASSWORD_RESET_TIMEOUT_DAYS and allow floats? Then you 
>> can just do 1/24 for an hour.
>>
>> On 21 September 2017 at 09:50, Eddy C  wrote:
>>
>>> I think Minute, with default value 30 or 60, is the best unit for this 
>>> setting.
>>>
>>> 3 minutes (even 1) is short enough for edge case and 720 (12 hours) also 
>>> looks good.
>>>
>>> On Thursday, September 21, 2017 at 6:22:20 PM UTC+10, Tom Forbes wrote:
>>>>
>>>> I think we shouldn't shoe-horn a timedelta into the existing setting, 
>>>> so my vote is with the second option, but I think a timedelta is much more 
>>>> readable than just an integer.
>>>>
>>>> Also, the existing 3 day timeout for password links is quite surprising 
>>>> from a security point of view. The consultants I work with would flag up a 
>>>> token that lasts longer than 12 hours as an issue during a pentest. 
>>>>
>>>> IMO a new, far shorter default should be added to this setting.
>>>>
>>>> On 21 Sep 2017 03:56, "Zhiqiang Liu"  wrote:
>>>>
>>>> I need general consensus on how to proceed with supporting password 
>>>> expire time to be under a day. Currently it is not possible because we use 
>>>> PASSWORD_RESET_TIMEOUT_DAYS.
>>>>
>>>> In ticket 28622 <https://code.djangoproject.com/ticket/28622> we have 
>>>> two options. 
>>>>
>>>> One is to continue to use the same setting PASSWORD_RESET_TIMEOUT_DAYS, 
>>>> but change the value to non-integer (such as timedelta) so we can send 
>>>> hours, minutes, etc to it.
>>>>
>>>> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT 
>>>> which takes seconds.To support backward compatibility, I think we should 
>>>> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
>>>> PASSWORD_RESET_TIMEOUT when provided.
>>>>
>>>> I'm unsure which one is better, so inputs are welcome.
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/django-developers/c8e96008-eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-developers/c8e96008-eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/6d0d4251-64bc-40a0-b191-9c

Re: There should be a way to make Templates substitution to raise an exception on error

[Zhiqiang Liu]

This is not 100% related to the ticket, but something to think about.

In ReactJS, there a concept called propTypes, which will check all props 
(they are similar to context in concept I think) listed with types in UI 
component.

So maybe we can have something similar in django template system that a 
template can have an attribute called contextTypes and it can be a dict of 
context the template may have. It doesn't need to have all possible context 
values, only include those you want to make sure the context are passed and 
value types are correct.

A simple example can be


contextTypes = {
"name": contextTypes.string.isRequired,

}



On Thursday, September 21, 2017 at 7:05:28 AM UTC-4, Shreyas Pandya wrote:
>
> Hi All,
>
> What is your opinion on having an option to raise an error in template if 
> variable is not found in context. This may be useful for automated  tests 
> as discussed in ticket. 
>
> reference ticket #28618  ; 
>
> Thanks
>
> regards
> Shreyas
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/46bb3674-3eeb-4b8c-8599-7950036e92f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: There should be a way to make Templates substitution to raise an exception on error

[Zhiqiang Liu]

To continue the previous comment.

template can raise error give warning if required contexts are not provided 
or the types are not correct. You can have something not isRequired in 
contextTypes too but types can be check if the context is actually passed 
to template.


On Thursday, September 21, 2017 at 9:35:05 AM UTC-4, Zhiqiang Liu wrote:
>
> This is not 100% related to the ticket, but something to think about.
>
> In ReactJS, there a concept called propTypes, which will check all props 
> (they are similar to context in concept I think) listed with types in UI 
> component.
>
> So maybe we can have something similar in django template system that a 
> template can have an attribute called contextTypes and it can be a dict of 
> context the template may have. It doesn't need to have all possible context 
> values, only include those you want to make sure the context are passed and 
> value types are correct.
>
> A simple example can be
>
>
> contextTypes = {
> "name": contextTypes.string.isRequired,
>
> }
>
>
>
> On Thursday, September 21, 2017 at 7:05:28 AM UTC-4, Shreyas Pandya wrote:
>>
>> Hi All,
>>
>> What is your opinion on having an option to raise an error in template if 
>> variable is not found in context. This may be useful for automated  tests 
>> as discussed in ticket. 
>>
>> reference ticket #28618 <https://code.djangoproject.com/ticket/28618> ; 
>>
>> Thanks
>>
>> regards
>> Shreyas
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0e82ce82-3a0d-44a6-9f68-f359a7354eb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Zhiqiang Liu]

If most agree, I will proceed with using seconds.

It is a good idea for the potential documentation Dylan!

Zach

On Thursday, September 21, 2017 at 10:09:50 AM UTC-4, Dylan Reinhold wrote:
>
> I still think seconds are the way to go, but maybe the documentation could 
> give a clue that timedelta().seconds can be used for readability
> PASSWORD_RESET_TIMEOUT = datetime.timedelta(hours=6, minutes=30).seconds
>
> Dylan
>
> On Thu, Sep 21, 2017 at 6:14 AM, Zhiqiang Liu  > wrote:
>
>> Yeah I don't think float number of days is a good choice because the 
>> calculation will be weird with precision issues.
>>
>> I think it makes sense to use PASSWORD_RESET_TIMEOUT. For timedelta vs. 
>> integer seconds. Timedelta has the benefit of readability, but integer has 
>> the benefit of simplicity. I think in SETTINGS everything should be as 
>> simple as possible, so I think integer seconds is a better choice here. And 
>> it is used in most applications too.
>>
>>
>> On Thursday, September 21, 2017 at 8:56:36 AM UTC-4, charettes wrote:
>>>
>>> That's what I proposed on the ticket but I feel like it felt odd to me, 
>>> the setting name does't suggest this is possible and it might be hard to 
>>> achieve exact second precious because of float rounding?
>>>
>>> In my opinion introducing PASSWORD_RESET_TIMEOUT with timedelta support 
>>> would be the best option.
>>>
>>> Simon
>>>
>>> Le jeudi 21 septembre 2017 05:26:23 UTC-4, Adam Johnson a écrit :
>>>>
>>>> Why not just keep PASSWORD_RESET_TIMEOUT_DAYS and allow floats? Then 
>>>> you can just do 1/24 for an hour.
>>>>
>>>> On 21 September 2017 at 09:50, Eddy C  wrote:
>>>>
>>>>> I think Minute, with default value 30 or 60, is the best unit for this 
>>>>> setting.
>>>>>
>>>>> 3 minutes (even 1) is short enough for edge case and 720 (12 hours) 
>>>>> also looks good.
>>>>>
>>>>> On Thursday, September 21, 2017 at 6:22:20 PM UTC+10, Tom Forbes wrote:
>>>>>>
>>>>>> I think we shouldn't shoe-horn a timedelta into the existing setting, 
>>>>>> so my vote is with the second option, but I think a timedelta is much 
>>>>>> more 
>>>>>> readable than just an integer.
>>>>>>
>>>>>> Also, the existing 3 day timeout for password links is quite 
>>>>>> surprising from a security point of view. The consultants I work with 
>>>>>> would 
>>>>>> flag up a token that lasts longer than 12 hours as an issue during a 
>>>>>> pentest. 
>>>>>>
>>>>>> IMO a new, far shorter default should be added to this setting.
>>>>>>
>>>>>> On 21 Sep 2017 03:56, "Zhiqiang Liu"  wrote:
>>>>>>
>>>>>> I need general consensus on how to proceed with supporting password 
>>>>>> expire time to be under a day. Currently it is not possible because we 
>>>>>> use 
>>>>>> PASSWORD_RESET_TIMEOUT_DAYS.
>>>>>>
>>>>>> In ticket 28622 <https://code.djangoproject.com/ticket/28622> we 
>>>>>> have two options. 
>>>>>>
>>>>>> One is to continue to use the same setting 
>>>>>> PASSWORD_RESET_TIMEOUT_DAYS, but change the value to non-integer (such 
>>>>>> as 
>>>>>> timedelta) so we can send hours, minutes, etc to it.
>>>>>>
>>>>>> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT 
>>>>>> which takes seconds.To support backward compatibility, I think we should 
>>>>>> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
>>>>>> PASSWORD_RESET_TIMEOUT when provided.
>>>>>>
>>>>>> I'm unsure which one is better, so inputs are welcome.
>>>>>>
>>>>>> -- 
>>>>>> You received this message because you are subscribed to the Google 
>>>>>> Groups "Django developers (Contributions to Django itself)" 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.
>>>>>> Vi

Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

Most of the times it is redirected to v1.6, sometimes 1.10, not sure why it 
happens?

Are people aware of that?


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/98fcb742-83a4-4b5b-ad7a-5b4e8c47769c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ConnectionResetError in test_closes_connection_without_content_length

[Zhiqiang Liu]

To follow up, I set up a new macbook pro today with python3.6 and OXS10.12, 
and I got the same error.

On Wednesday, September 20, 2017 at 8:39:23 PM UTC-4, Zhiqiang Liu wrote:
>
> Yeah I believe it is a new test, so I can't test if it is working for 1.11.
>>
>
> I did get it to pass after adding except like this
>
>  try:
> conn.request('GET', '/example_view/', headers={'Connection': 
> 'keep-alive'})
> response = conn.getresponse().read()
> conn.request('GET', '/example_view/', headers={'Connection': 
> 'close'})
> with self.assertRaises(RemoteDisconnected, msg='Server did not 
> close the connection'):
> try:
> conn.getresponse()
> except ConnectionAbortedError:
> if sys.platform == 'win32':
> self.skipTest('Ignore nondeterministic failure on 
> Windows.')
> except ConnectionResetError:
> self.skipTest('Ignore failure.')
>
> Tom because you said it varies by OS, so I am not sure which message to 
> add so I just used 'Ignore failure', should I use something else? I can 
> submit a simple PR for that.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1aa49196-ef38-418f-8aa0-57e3c9d806cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Zhiqiang Liu]

+1, also it is a good point that all things in settings should be simple, 
complex date object does not belong there, at least should not be required.

It should be for the majority of users as possible.

On Friday, September 22, 2017 at 4:53:55 AM UTC-4, Adam Johnson wrote:
>
> +1 for consistency too. You can always use a timedelta if you want, with 
> total_seconds() (not seconds as mentioned before😉).
>
> On 22 September 2017 at 08:48, Florian Apolloner  > wrote:
>
>> +1 for consistency
>>
>> On Friday, September 22, 2017 at 2:46:14 AM UTC+2, Collin Anderson wrote:
>>>
>>> Seconds is consistent with all of the other settings, even for long ones 
>>> like CSRF_COOKIE_AGE and SESSION_COOKIE_AGE. It also means you can avoid 
>>> importing datetime in your settings file.
>>>
>>> On Thu, Sep 21, 2017 at 8:36 PM, Tom Forbes  wrote:
>>>
>>>> It also seems odd to express it as seconds, it's often going to be a 
>>>> large value between an hour and several days and the lowest resolution for 
>>>> the value anyone would need is minutes.
>>>>
>>>> On 22 Sep 2017 01:29, "Tom Forbes"  wrote:
>>>>
>>>>> I would still vote for a timedelta, im not sure if there is a strong 
>>>>> consensus in the thread. 
>>>>>
>>>>> Representing the time as seconds always irks me, you can make it more 
>>>>> readable by using multiplication but you often end up with a comment 
>>>>> anyway 
>>>>> and it doesn't scan nearly as well. Having to do 'timedelta.seconds' is 
>>>>> OK, 
>>>>> but it seems a bit like busywork. 
>>>>>
>>>>> It's a small thing but I don't see any practical problem with just 
>>>>> accepting a timedelta, they are nicer to work with in the settings file 
>>>>> itself and within Django, especially if the TimestampSigner accepts them 
>>>>> natively and we start to use that.
>>>>>
>>>>> On 21 Sep 2017 22:41, "Zhiqiang Liu"  wrote:
>>>>>
>>>>> If most agree, I will proceed with using seconds.
>>>>>
>>>>> It is a good idea for the potential documentation Dylan!
>>>>>
>>>>> Zach
>>>>>
>>>>>
>>>>> On Thursday, September 21, 2017 at 10:09:50 AM UTC-4, Dylan Reinhold 
>>>>> wrote:
>>>>>
>>>>>> I still think seconds are the way to go, but maybe the documentation 
>>>>>> could give a clue that timedelta().seconds can be used for readability
>>>>>> PASSWORD_RESET_TIMEOUT = datetime.timedelta(hours=6, 
>>>>>> minutes=30).seconds
>>>>>>
>>>>>> Dylan
>>>>>>
>>>>>> On Thu, Sep 21, 2017 at 6:14 AM, Zhiqiang Liu  
>>>>>> wrote:
>>>>>>
>>>>>>> Yeah I don't think float number of days is a good choice because the 
>>>>>>> calculation will be weird with precision issues.
>>>>>>>
>>>>>>> I think it makes sense to use PASSWORD_RESET_TIMEOUT. For timedelta 
>>>>>>> vs. integer seconds. Timedelta has the benefit of readability, but 
>>>>>>> integer 
>>>>>>> has the benefit of simplicity. I think in SETTINGS everything should be 
>>>>>>> as 
>>>>>>> simple as possible, so I think integer seconds is a better choice here. 
>>>>>>> And 
>>>>>>> it is used in most applications too.
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, September 21, 2017 at 8:56:36 AM UTC-4, charettes wrote:
>>>>>>>>
>>>>>>>> That's what I proposed on the ticket but I feel like it felt odd to 
>>>>>>>> me, the setting name does't suggest this is possible and it might be 
>>>>>>>> hard 
>>>>>>>> to achieve exact second precious because of float rounding?
>>>>>>>>
>>>>>>>> In my opinion introducing PASSWORD_RESET_TIMEOUT with timedelta 
>>>>>>>> support would be the best option.
>>>>>>>>
>>>>>>>> Simon
>>>>>>>>
>>>>>>>> Le jeudi 21 septembre 2017 05:26:23 UTC-4, Adam Johnson a écrit :

Re: Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

even https://docs.djangoproject.com/en/stable/ directs me to /1.6/ and will 
give me 404. This has been bothering me for a while and I don't know why it 
doesn't happen to many. I set up a brand new laptop yesterday and still 
have the same issue.

On Friday, September 22, 2017 at 7:38:10 AM UTC-4, Florian Apolloner wrote:
>
> This is why we already have https://docs.djangoproject.com/en/stable/ 
> links. From a SEO perspective we are going to stay with versioned URLs and 
> redirects.
>
> On Friday, September 22, 2017 at 1:03:26 PM UTC+2, Sai wrote:
>>
>> Guys i have an suggestion.Instead of showing 
>> *https://docs.djangoproject.com/en/1.11/ 
>> <https://docs.djangoproject.com/en/1.11/>* we can show it as 
>> *https://docs.djangoproject.com/en/latest/ 
>> <https://docs.djangoproject.com/en/latest/>* . Every time we have new 
>> release we can proxy pass */latest *end point to latest version 
>> documentation.It will take time but in few days it will be uniform across 
>> all websites. 
>>
>>  P.H.S.Phanindhra,
>> AE13B020,
>> 4th year Undergraduate,
>> Aerospace Engineering,
>> IIT Madras,Chennai.
>>
>> On 22 September 2017 at 08:08, Dylan Reinhold  wrote:
>>
>>> From the main site, or from other site like stack-overflow or google? 
>>> From the main site I get 1.11.
>>> From another site you cant control what links are used.
>>>
>>> Dylan
>>>
>>> On Thu, Sep 21, 2017 at 6:07 PM, Zhiqiang Liu  
>>> wrote:
>>>
>>>> Most of the times it is redirected to v1.6, sometimes 1.10, not sure 
>>>> why it happens?
>>>>
>>>> Are people aware of that?
>>>>
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/django-developers/98fcb742-83a4-4b5b-ad7a-5b4e8c47769c%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-developers/98fcb742-83a4-4b5b-ad7a-5b4e8c47769c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CAHtg44A4q2QDnAzWAkcLmqyONp2KM%3DBY_U4UtiEMb8LwutisEA%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/CAHtg44A4q2QDnAzWAkcLmqyONp2KM%3DBY_U4UtiEMb8LwutisEA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ffbd9c60-7d7e-465b-8c8f-ef65ac19e128%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

Here it is 
HTTP/1.1 302 Found
Server: nginx
Date: Fri, 22 Sep 2017 17:26:03 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
x-content-type-options: nosniff
Content-Language: en
Location: /en/1.11/
x-xss-protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Vary: Accept-Language, Cookie
Access-Control-Allow-Origin: https://code.djangoproject.com
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Public-Key-Pins-Report-Only: 
pin-sha256="og15UrKd7sLz7rIaFIsLD/n3qgqRrXmSQ37/d/8sqi8="; 
pin-sha256="deadbeefcafedeadbeefcafedeadbeefcafe111="; max-age=300; 
includeSubDomains; 
report-uri="https://djangoproject.report-uri.io/r/default/hpkp/reportOnly";




On Friday, September 22, 2017 at 10:38:13 AM UTC-4, Florian Apolloner wrote:
>
> Please provide the output without the grep -- I'd like to see all headers. 
> We are sending a 302 redirect to /en/1.11/ for sure ;)
>
> On Friday, September 22, 2017 at 4:22:03 PM UTC+2, Jamesie Pic wrote:
>>
>> Amazing, what's the output when you try `curl -I 
>> https://docs.djangoproject.com/en/stable/ | grep Location` ?
>>
>> If none, try without the `| grep Location`.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a68d75a9-8c75-429f-a16e-bdbfb609d1e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

Ah it used to happen to all my browsers, now with the new laptop it only 
happens to Chrome, so it is browser related I think.

On Friday, September 22, 2017 at 1:27:08 PM UTC-4, Zhiqiang Liu wrote:
>
> Here it is 
> HTTP/1.1 302 Found
> Server: nginx
> Date: Fri, 22 Sep 2017 17:26:03 GMT
> Content-Type: text/html; charset=utf-8
> Content-Length: 0
> Connection: keep-alive
> x-content-type-options: nosniff
> Content-Language: en
> Location: /en/1.11/
> x-xss-protection: 1; mode=block
> X-Frame-Options: SAMEORIGIN
> Vary: Accept-Language, Cookie
> Access-Control-Allow-Origin: https://code.djangoproject.com
> Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
> Public-Key-Pins-Report-Only: 
> pin-sha256="og15UrKd7sLz7rIaFIsLD/n3qgqRrXmSQ37/d/8sqi8="; 
> pin-sha256="deadbeefcafedeadbeefcafedeadbeefcafe111="; max-age=300; 
> includeSubDomains; report-uri="
> https://djangoproject.report-uri.io/r/default/hpkp/reportOnly";
>
>
>
>
> On Friday, September 22, 2017 at 10:38:13 AM UTC-4, Florian Apolloner 
> wrote:
>>
>> Please provide the output without the grep -- I'd like to see all 
>> headers. We are sending a 302 redirect to /en/1.11/ for sure ;)
>>
>> On Friday, September 22, 2017 at 4:22:03 PM UTC+2, Jamesie Pic wrote:
>>>
>>> Amazing, what's the output when you try `curl -I 
>>> https://docs.djangoproject.com/en/stable/ | grep Location` ?
>>>
>>> If none, try without the `| grep Location`.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e8695ce9-408b-4143-b33d-a717693571d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

Finally found it out. There's a browser extension called django version 
switcher hidding in my browser, which is carried over to my new laptop when 
I set it up. The extension will intercept your request to django docs site 
and redirect you to a version it remembered. 

It must be long ago because I didn't remember there is such a thing. 

Thanks for all the help:)

On Friday, September 22, 2017 at 1:30:30 PM UTC-4, Zhiqiang Liu wrote:
>
> Ah it used to happen to all my browsers, now with the new laptop it only 
> happens to Chrome, so it is browser related I think.
>
> On Friday, September 22, 2017 at 1:27:08 PM UTC-4, Zhiqiang Liu wrote:
>>
>> Here it is 
>> HTTP/1.1 302 Found
>> Server: nginx
>> Date: Fri, 22 Sep 2017 17:26:03 GMT
>> Content-Type: text/html; charset=utf-8
>> Content-Length: 0
>> Connection: keep-alive
>> x-content-type-options: nosniff
>> Content-Language: en
>> Location: /en/1.11/
>> x-xss-protection: 1; mode=block
>> X-Frame-Options: SAMEORIGIN
>> Vary: Accept-Language, Cookie
>> Access-Control-Allow-Origin: https://code.djangoproject.com
>> Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
>> Public-Key-Pins-Report-Only: 
>> pin-sha256="og15UrKd7sLz7rIaFIsLD/n3qgqRrXmSQ37/d/8sqi8="; 
>> pin-sha256="deadbeefcafedeadbeefcafedeadbeefcafe111="; max-age=300; 
>> includeSubDomains; report-uri="
>> https://djangoproject.report-uri.io/r/default/hpkp/reportOnly";
>>
>>
>>
>>
>> On Friday, September 22, 2017 at 10:38:13 AM UTC-4, Florian Apolloner 
>> wrote:
>>>
>>> Please provide the output without the grep -- I'd like to see all 
>>> headers. We are sending a 302 redirect to /en/1.11/ for sure ;)
>>>
>>> On Friday, September 22, 2017 at 4:22:03 PM UTC+2, Jamesie Pic wrote:
>>>>
>>>> Amazing, what's the output when you try `curl -I 
>>>> https://docs.djangoproject.com/en/stable/ | grep Location` ?
>>>>
>>>> If none, try without the `| grep Location`.
>>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c67d40f8-c1c9-46a7-a0c6-cd0f21ef31e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Zhiqiang Liu]

o think this works like a short, 6 digit 
> OTP, for which 3 days would be far too long ( see 
> https://sakurity.com/blog/2015/07/18/2fa.html ). We could put a note in 
> the docs about this, I don't know how to do that in a succinct way apart 
> from to link to a copy of this email or something.
>
> However, if we really do 'need' this change, we should at least keep the 
> default to what it is now, and put a notice in the docs saying that 
> reducing it hurts usability and makes no practical difference to security. 
> Since we would be causing an upgrade bump and breaking existing links, we 
> may as well also switch to TimestampSigner (the password reset code was 
> originally written before that existed), which would also mean changing 
> urlconfs I imagine. This would also require a significant section in the 
> upgrade notes. (In my book, this is a further argument against doing this 
> change at all).
>
>
> Regards,
> Luke
> On 21/09/17 12:25, Adam Johnson wrote:
>
> Why not just keep PASSWORD_RESET_TIMEOUT_DAYS and allow floats? Then you 
> can just do 1/24 for an hour.
>
> On 21 September 2017 at 09:50, Eddy C > 
> wrote:
>
>> I think Minute, with default value 30 or 60, is the best unit for this 
>> setting. 
>>
>> 3 minutes (even 1) is short enough for edge case and 720 (12 hours) also 
>> looks good.
>>
>> On Thursday, September 21, 2017 at 6:22:20 PM UTC+10, Tom Forbes wrote: 
>>>
>>> I think we shouldn't shoe-horn a timedelta into the existing setting, so 
>>> my vote is with the second option, but I think a timedelta is much more 
>>> readable than just an integer.
>>>
>>> Also, the existing 3 day timeout for password links is quite surprising 
>>> from a security point of view. The consultants I work with would flag up a 
>>> token that lasts longer than 12 hours as an issue during a pentest. 
>>>
>>> IMO a new, far shorter default should be added to this setting.
>>>
>>> On 21 Sep 2017 03:56, "Zhiqiang Liu"  wrote:
>>>
>>> I need general consensus on how to proceed with supporting password 
>>> expire time to be under a day. Currently it is not possible because we use 
>>> PASSWORD_RESET_TIMEOUT_DAYS. 
>>>
>>> In ticket 28622 <https://code.djangoproject.com/ticket/28622> we have 
>>> two options. 
>>>
>>> One is to continue to use the same setting PASSWORD_RESET_TIMEOUT_DAYS, 
>>> but change the value to non-integer (such as timedelta) so we can send 
>>> hours, minutes, etc to it.
>>>
>>> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT 
>>> which takes seconds.To support backward compatibility, I think we should 
>>> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
>>> PASSWORD_RESET_TIMEOUT when provided.
>>>
>>> I'm unsure which one is better, so inputs are welcome.
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/c8e96008-eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/c8e96008-eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%40googlegroups.com?utm_medium=email&utm_source

Re: ConnectionResetError in test_closes_connection_without_content_length

[Zhiqiang Liu]

Hi Chris, 

I did installed sqlite through brew install sqlite, the error still happens.

On Friday, September 22, 2017 at 7:52:53 AM UTC-4, Chris Foresman wrote:
>
> The problem is the version of SQLite included in recent versions of macOS. 
> The easiest fix we saw was installing Homebrew and then doing a `brew 
> install sqlite`. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/18828bdd-e11d-41c6-91c9-345c3d342e0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.