On Thu, Aug 25, 2011 at 5:58 PM, Subhranath Chunder <subhran...@gmail.com> wrote: > I got the idea of what was happening looking at the behavior pattern itself. > But, what I was not sure whether these behaviors were defined or just > working like that. Which might lead to some other inconsistencies. > As, in my case the fragment was coming from some other third-party source. > Facebook as in this case. > So, I may not always have control over the fragment with which facebook > decides to hit on my app API. > Django seems to currently allow the sending of 302 response, with fragment, > as we saw in the second scenario. > And since it is allowing us to specify the fragment, which the browsers > seems to honor as of now. Shouldn't we also be able to explicitly specify > it's removal? > Maybe I'm asking too much out of the implementation, as I don't see that > much details in the RFC you mentioned. :) >
It's interesting that it is Facebook - the MS developer whose blog I linked to discovered that IE handled it differently to the others when trying to understand why Facebook redirects didn't work. ISTR that setting fragments in the Location header is forbidden in the spec, but that every UA handles it (like a lot of things where the spec is misleading or just plain wrong!). I think the httpbis working group will deal with this when they revisit RFC 2616. There is also this document from the w3, Common User Agent Problems, which is meant for browser implementors. It discusses what the browser should do when it has to choose which fragment to select - the one on the original request, or the one returned in the Location header on the redirect: http://www.w3.org/TR/cuap#uri You'll notice that it says the behaviour is wrong, and points at the draft spec (expired 2000) to confirm that.... The nice thing about standards is that there are so many to choose from :) Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.