> It should not migrate - there is real value in knowing both settings > separately.
Agreed that there is real knowledge in knowing both -- however in many situations having both is confusing and breaks plugins or code It's up to the developer of an application if they want it to be aware of an internal proxy or not. On some projects I may need to know which one of my loadbalancers something came from. On others I may need to know if there is any sort of proxying before it gets to me. On most projects though, the only IP that I care about is the end-user --and I don't care about information my reverse proxy puts in there. It's much simpler to write code that only has to deal with REMOTE_ADDR , and only validate the x-forwarded-for headers -- and possibly stash that elsewhere -- in something that runs before my application logic begins. in perl i can do that with specific phases in the apache request process; in pylons i can do it in middleware. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
