I have a url shortener and this is the view:
def reroute(request, shorthand, parameter=None):
....
#constructs url
url = ...
return HttpResponsePermanentRedirect(url)
Basically I take in a url http://localhost:8000/silly-big-cat and route that to whatever the user supplied when this was created. The behavior that I started to notice was that the browser would hit the server once, if I went to that link again the browser somehow remembers where it was redirected last time and I see no indication of it hitting the server. Is the browser somehow caching this? If this is the case, is there a way to prevent this caching from happening? silly-big-cat's URL might change in the future but the browser may still be stuck with the old URL.
Is the browser somehow caching this?
Most browsers will indeed remember permanent redirects, and therefore not bother to first visit the URL and then follow the redirect.
silly-big-cat's URL might change in the future but the browser may still be stuck with the old URL.
Do not make it permanent, but use a simple HttpResponseRedirect [Django-doc]. This has as status code, if you do not pass permanent=True, 302, whereas a permanent one has HTTP response 301.
Related
In the past I used the Post/Redirect/Get pattern:
the html for was submitted to the server via POST
the server processed the data.
if everything was ok, the server responsed with a http 302 (redirect
the client redirected the page to the new location.
Is this still needed if you submit html fragments via htmx?
By and large no, you will not need to implement the PRG pattern.
Since htmx uses AJAX for most interactions, there is no request sitting in the browser history, and hitting refresh will not re-submit a POST (or DELETE or whatever).
That said, htmx trys to be compatible with the PRG pattern, and tries to update the URL if a redirect occurs by detecting the :
https://github.com/bigskysoftware/htmx/blob/1d4c79490e491813ffb780354ec5df6d080b1e09/src/htmx.js#L2146
https://github.com/bigskysoftware/htmx/blob/1d4c79490e491813ffb780354ec5df6d080b1e09/src/htmx.js#L1851
If you do something like inline editing:
https://htmx.org/examples/click-to-edit/
The point becomes moot to a large extent, since you can have the edit UI at the same URL as the view URL.
Serving a Permanent 301 redirect or a Temporary 302 redirect in Django is very straightforward using the redirect shortcut (which in turn just uses HttpResponsePermanentRedirect or HttpResponseRedirect)
I need to count how many times a redirect was used, but if I use 301, my view is only hit on the first request. Browsers presumably cache the new URL, because successive requests don't hit my view.
And yet I can see that many URL shortening services (http://searchengineland.com/analysis-which-url-shortening-service-should-you-use-17204) do use 301 AND count hits.
How do they do this? I can see they write cookies, but I don't understand what this buys you?
#Alisdair is correct. When I created a short url in various services and hit refresh, I saw the hit count increase, but did not consider that it was not actually me, but a bot watching newly created short URLs :) Yes, 301 Permanent redirect allws them to track only the initial request.
I'm trying to make integration of etherpad-lite in the CMS Plone, following Example 1 of the official documentation http://etherpad.org/doc/v1.2.7/
Portal places the cookie "sessionID" with the given value on the client and creates an iframe including the pad.
Everythings goes well except for the cookie. Reading documentation the best pratice seems to make etherpad-lite in the same domain under a specific path. This is what I have done using /pad/ path.
Plone side if no session has been created, I created on, I add a cookie and then I'm doing a redirect to the same page to be sure the cookie is in the browser.
As a results my cookie is added to the request of the main page but not ob the iframe request.
Here is the google chrome console network tab for the main page and the iframe:
http://toutpt.makina-corpus.org/en/images/cookie-in-iframe/
The code corresponding to the setCookie is at https://github.com/toutpt/collective.etherpad/blob/master/collective/etherpad/archetypes.py#L100
For posterity, here's the answer from #AskoSoukka identified and "accepted" in the comments above:
How does the actual cookie stored in you browser look like? Probably, you need to explicitly specify path="/" in setCookie kwargs to make it work for the whole domain.
I'm trying to redirect the browser back to the site root and also pass a variable in order to trigger a JS notification function... This is all with Django.
What I have now is this:
urls.py:
url(r'^accounts/password/reset/complete/$', views.passwordResetComplete,
name='password_reset_complete'),
views.py:
def passwordResetComplete(theRequest):
return redirect(home(theRequest, 'Password reset successful'))
def home(theRequest, myMessage=None):
.........
return render_to_response('new/index.html',
{
"myTopbar": myTopbar,
"isLoggedIn": isLoggedIn,
"myMessage": myMessage
},
context_instance=RequestContext(theRequest)
)
I get this error:
NoReverseMatch: Error importing 'Content-Type: text/html; charset=utf-8.......(gives full HTML of page)
I've been working around a few different solutions and nothing seems to work in the way that I need. The closest I've got is to redirect to '/?query-string' with a JS function in root to check for that query-string and run the function if it's present. However, that leaves the query-string in the URL for the duration of the user's navigation of the site (which is 100% AJAX). I want to avoid having any strings/long hrefs in the URL.
Would be really grateful if anyone can tell me how to solve this problem.
HTTP is a stateless protocol, which means that each and every request is entirely unique and separated from anything and everything that has ever been done before. Put more simply, the only way (in HTTP) to "pass a variable" with a URL is to add it to the URL itself (/someobject/1/, for example, where 1 is an object id) or in the querystring (?someobject=1). Either way, the information is embedded in the URL and it's up to your application to decipher that information out of the URL and do something with it.
The concept of a "session" was introduced as a way to provide state to the stateless protocol that is HTTP. The way it works is that the server sends the client a cookie containing some identifiable information (usually, just a session id). Then, the client sends the cookie back to the server in the request headers with every request. The server sees the cookie, looks up the session and continues on seamlessly with whatever is in progress. This is not true state, but it does provide the ability to essentially mimic state, and it's the only way to pass data between requests without actually embedding the data in the URL.
If all you need to return back is a message to the user such as "Password reset successful", you can and should simply use Django's messages framework, which itself uses the session pass the message. It sets a cookie for the client, so that you can redirect to any URL. The cookie will be passed back with the request for that new URL, and Django will add the message from the session into the appropriate place in your template for that URL.
If you need to actually invoke a bit of JavaScript, then you should make the request via AJAX. In the response, you can return any data you want in via JSON (and act on that data however you like) or even return Javascript to be run.
Following the redirect docs, you cannot simply redirect to a view, but only to a url or an object/view that is a assigned to a url already. Thus, you have 2 options:
a) Call the view directly like that:
return home(theRequest, 'Password reset successful')
b) Add a Url patterns like that:
url(r'^your_patterns/$', views.home, msg='',name='home'),
Then you will be able to do what you initally did:
return redirect(views.home,('Password reset successful',))
or from my point of view, even tidier:
return redirect('home',('Password reset successful',))
I'm stuck in a cookie related question. I want to write a program that can automate download the attachments of this forum. So I should maintain the cookies this site send to me. When I send a GET request in my program to the login page, I got the cookie such as Set-Cookie: sso_sid=0589a967; domain=.it168.com in my program. Now if I use a cookie viewer such as cookie monster and send the same GET request, my program get the same result, but the cookie viewer shows that the site also send me two cookies which are:
testcookie http://get2know.it/myimages/2009-12-27_072438.jpg and token http://get2know.it/myimages/2009-12-27_072442.jpg
My question is: Where did the two cookie came from? Why they did not show in my program?
Thanks.
Your best bet to figure out screen-scraping problems like this one is to use Fiddler. Using Fiddler, you can compare exactly what is going over the wire in your app vs. when accessing the site from a browser. I suspect you'll see some difference between headers sent by your app vs. headers sent by the browser-- this will likley account for the difference you're seeing.
Next, you can do one of two things:
change your app to send exactly the headers that the browser does (and, if you do this, you should get exactly the response that a real browser gets).
using Fiddler's "request builder" feature, start removing headers one by one and re-issuing the request. At some point, you'll remove a header which makes the response not match the response you're looking for. That means that header is required. Continue for all other headers until you have a list of headers that are required by the site to yield the response you want.
Personally, I like option #2 since it requires a minimum amount of header-setting code, although it's harder initially to figure out which headers the site requires.
On your actual question of why you're seeing 2 cookies, only the diagnosis above will tell you for sure, but I suspect it may have to do with the mechanism that some sites use to detect clients who don't accept cookies. On the first request in a session, many sites will "probe" a client to see if the client accepts cookies. Typically they'll do this:
if the request doesn't have a cookie on it, the site will redirect the client to a special "cookie setting" URL.
The redirect response, in addition to having a Location: header which does the redirect, will also return a Set-Cookie header to set the cookie. The redirect will typically contain the original URL as a query string parameter.
The server-side handler for the "cookie setter" page will then look at the incoming cookie. If it's blank, this means that the user's browser is set to not accept cookies, and the site will typically redirect the user to a "sorry, you must use cookies to use this site" page.
If, however, there is a cookie header send to the "cookie setter" URL, then the client does in fact accept cookies, and the handler will simply redirect the client back to the original URL.
The original URL, once you move on to the next page, may add an additional cookie (e.g. for a login token).
Anyway, that's one way you could end up with two cookies. Only diagnosis with Fiddler (or a similar tool) will tell you for sure, though.