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. :)
On Thu, Aug 25, 2011 at 9:23 PM, Tom Evans <tevans...@googlemail.com> wrote:
> On Thu, Aug 25, 2011 at 4:04 PM, Subhranath Chunder
> <subhran...@gmail.com> wrote:
> > Yes, I do understand that fragment identifiers are not sent to the
> server.
> > But, I was not talking about that.
> > Infact, I was talking about the fragments send in the response as http
> 302
> > response specifically.
> > Maybe, I'll put a little code snippet below to explain the case better:
> :)
> > urls.py
> > =====
> > ...
> > url(r'^$', 'dummy_app.views.index'),
> > url(r'^action/$', 'dummy_app.views.redirect_handler'),
> > ...
> > views.py
> > =====
> > ...
> > def index(request):
> > if request.method == "GET":
> > return HttpResponse("Index Page <form method='post'><input
> > type="button" value="Try" /></form>")
> > else:
> > return HttpResponseRedirect("/action/")
> > def redirect_handler(request):
> > return HttpResponse("Hello")
> > ...
> > Scenario 1:
> > User opens the browser, and hits URL : http://<server>/#test -> Gets to
> see
> > "Index Page" with a button with text "Try" -> browser url shown as
> > "http://<server>/#test" -> User clicks the button -> New page content is
> > "Hello" -> current url in browser is "http://<server>/action/#test"
>
> This only happens because you have omitted the action attribute from
> the form, so the browser submits to the exact same URL. When Django
> replies with a 302 'Found' response, it updates the URL with the found
> location, and keeps the identifier fragment, because that was part of
> the URL that was specified in the form.
>
> Basically, if you tell your browser to request /some/uri#fragment, and
> it receives a 302 response for that with location /some/other, it will
> interpolate the identifier fragment into the new url. If you don't
> want to have the identifier fragment in the new URL, don't link/post
> to a URL with the identifier fragment.
>
> > Scenario 2:
> > Changing the views.py as:
> > < return HttpResponseRedirect("/action/")
> > ...
> >> return HttpResponseRedirect("/action/#hello")
> > User opens the browser, and hits URL : http://<server>/#test -> Gets to
> see
> > "Index Page" with a button with text "Try" -> browser url shown as
> > "http://<server>/#test" -> User clicks the button -> New page content is
> > "Hello" -> current url in browser is "http://<server>/action/#hello"
> > Now, do you see the difference. The http response did have the fragment
> > specified while issuing the 302 in the second case.
> > So, my original question still stands still for me. Is this behavior
> defined
> > and expected?
> >
> >
>
> No, its not defined. Your browser is trying to help you out. Consider
> this scenario, you are browsing some documentation and click a link in
> the index:
>
> <a href="/docs/#section2">Section 2</a>
>
> Your browser now makes a request for /docs/. However, the index is out
> of date, and the correct URI is actually "/docs/index.html". The
> server sends an appropriate redirect:
>
> 302 Found
> Location: /docs/index.html
>
> Now, should your browser display /docs/index.html or
> /docs/index.html#section2? Your browser is deciding to do the latter,
> not all browsers do.
>
> This is discussed in an IETF draft from 1999:
> http://tools.ietf.org/html/draft-bos-http-redirect-00
>
> I can't see that its made it into an RFC proper yet. There is this
> blog post on MSDN, where an MSIE developer notices that MSIE doesn't
> do this, whilst Chrome, Opera and Firefox all do:
>
>
> http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
>
> 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.
>
>
--
Thanks,
Subhranath Chunder.
www.subhranath.com
--
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.
