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.
