<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 12, 2014 at 11:38 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 30 September 2014 11:47, Alan Kennedy <<a href="mailto:alan@xhaus.com">alan@xhaus.com</a>> wrote:<br>
<br>
> [Robert]<br>
>> So it sounds like it should be the responsibility of a middleware to<br>
>> renormalize the environment?<br>
><br>
> In order for that to be the case, you have strictly define what<br>
> "normalization" means.<br>
<br>
</span>For a given deployment its well defined. I agree that in general its not.<br>
<span class=""><br>
> I believe that it is not possible to fully specify "normalization", and that<br>
> any attempt to do so is futile.<br>
><br>
> If you want to attempt it for the specific scenarios that your particular<br>
> application has to deal with, then by all means code your version of<br>
> "normalization" into your application. Or write some middleware to do it.<br>
><br>
> But trying to make "normalization" a part of a WSGI-style specification is<br>
> impossible.<br>
<br>
</span>I don't recall proposing that it should be in a WSGI-style spec.<br>
<span class="im"><br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</span><div class=""><div class="h5">_______________________________________________<br>
Web-SIG mailing list<br>
<a href="mailto:Web-SIG@python.org">Web-SIG@python.org</a><br>
Web SIG: <a href="http://www.python.org/sigs/web-sig" target="_blank">http://www.python.org/sigs/web-sig</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com" target="_blank">https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">All this issue looks like the problem raised (and not yet solved) recently in Gunicorn when the REMOTE_ADDR has been handled more strictly and we removed all the X-Forward-* headers handling:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://github.com/benoitc/gunicorn/issues/797">https://github.com/benoitc/gunicorn/issues/797</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">There is another case to take in consideration, when your server is answering on unix sockets, so you don't have any TCP address to present. For now we answer with an empty field. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Also some application frameworks recently removed the middleware handling X-Forward-* headers. I wonder why.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">There is an RFC for forward headers: <a href="http://tools.ietf.org/html/rfc7239">http://tools.ietf.org/html/rfc7239</a> . For me instead of trying to change the strict behaviour of REMOTE_ADDR I wonder if we shouldn't rather add a new field to the environ. Thoughts?</div><div class="gmail_extra"><br></div><div class="gmail_extra">- benoit</div></div>