counts the number of hit on a website containing many JSPs

G

Garg

Hi All,

I am having a scenario in which I am having a full public website,
which won't require any login. I want to count the number of hits to
that website.

like :
1.
count = 0
if i hit http://www.abc.com/xyz1.jsp then count should become 1
and if i hit on http://www.abc.com/xyz2.jsp then count should become 2
(I am writing these urls in the address bar and clicking enter)

2.
count=0
if I hit http://www.abc.com/xyz1.jsp then count should become 1 and
then if I navigate to http://www.abc.com/xyz2.jsp by clicking any
hyper link on xyz1.jsp file the count should remain 1

I this i don't want to put the code in every JSP. I need a common
place.

So please tell me where I should put my code and variable count.

Thanks in advance,
Tarun
 
L

Lew

Garg said:
I am having a scenario in which I am having a full public website,
which won't require any login. I want to count the number of hits to
that website.

like :
1.
count = 0
if i [sic] hit http://www.abc.com/xyz1.jsp then count should become 1
and if i [sic] hit on http://www.abc.com/xyz2.jsp then count should become 2
(I am writing these urls in the address bar and clicking enter)

2.
count=0
if I hit http://www.abc.com/xyz1.jsp then count should become 1 and
then if I navigate tohttp://www.abc.com/xyz2.jspby clicking any
hyper link on xyz1.jsp file the count should remain 1

I this i [sic] don't want to put the code in every JSP. I need a common
place.

So please tell me where I should put my code and variable count.

If your application has an architecture that allows users to directly
type in a screen and bypass the welcome page, you will have great
difficulty with this.

The best-designed web applications have a single point of entry and
all navigation within the site is via links. actually, via active
controls like "submit" buttons that are under the complete control of
the application. With such a correct design, you can easily decide
what to count because the application controls all navigation.

If you insist on allowing people to access pages directly, make all
intra-application navigation via active buttons rather than links.
Then simply make sure that intra-application navigation includes a
"don't count" token in the submission, and if that token is absent
then count the hit.

You can include headers and footers for screens in web applications
via JSP groups in the web.xml. Alternatively, you can use the <
%@include ...> mechanism in each JSP.

Your counting question goes away entirely in a correctly-architected
application that controls its own navigation. If you use what I'll
kindly call a more chaotic architecture then the problem becomes
harder. If you use anchor links to navigate within the app, then I
don't think there really is a way to do what you want.

The Model-View-Controller architecture pattern will help you.
 
G

Garg

If your application has an architecture that allows users to directly
type in a screen and bypass the welcome page, you will have great
difficulty with this.

basically this is a simple website without any authentication and
using JSP/Servlets. And why this problem happen is because sometimes
user copy the url and send it to anyone and that guy clicks that url
and the page is open. But in this condition i am not able to increment
the count.

tarun
 
J

John B. Matthews

Garg said:
basically this is a simple website without any authentication and
using JSP/Servlets. And why this problem happen is because sometimes
user copy the url and send it to anyone and that guy clicks that url
and the page is open. But in this condition i am not able to increment
the count.

Tarun: Lew has proposed several excellent of ways to control access to
your web application that would preclude this problem. You cannot
"control access" and "not control access" at the same time.
 
A

Abhijat Vatsyayan

Garg said:
Hi All,

I am having a scenario in which I am having a full public website,
which won't require any login. I want to count the number of hits to
that website.

like :
1.
count = 0
if i hit http://www.abc.com/xyz1.jsp then count should become 1
and if i hit on http://www.abc.com/xyz2.jsp then count should become 2
(I am writing these urls in the address bar and clicking enter)

2.
count=0
if I hit http://www.abc.com/xyz1.jsp then count should become 1 and
then if I navigate to http://www.abc.com/xyz2.jsp by clicking any
hyper link on xyz1.jsp file the count should remain 1

I this i don't want to put the code in every JSP. I need a common
place.

So please tell me where I should put my code and variable count.

Thanks in advance,
Tarun
If you are willing to create a session for all users irrespective of
which URL they access, filters might help you. You can use a filter to
intercept all requests (or only the ones you want included in the
count), look at the session and figure out if this is a new user.
 
R

RedGrittyBrick

Garg said:
Hi All,

I am having a scenario in which I am having a full public website,
which won't require any login. I want to count the number of hits to
that website.

You don't say what you want to do with that count. I'll assume you want
to produce a report for your own study rather than present it to the
user (e.g. at the bottom of every web-page).

like :
1.
count = 0
if i hit http://www.abc.com/xyz1.jsp then count should become 1
and if i hit on http://www.abc.com/xyz2.jsp then count should become 2
(I am writing these urls in the address bar and clicking enter)

2.
count=0
if I hit http://www.abc.com/xyz1.jsp then count should become 1 and
then if I navigate to http://www.abc.com/xyz2.jsp by clicking any
hyper link on xyz1.jsp file the count should remain 1

I this i don't want to put the code in every JSP. I need a common
place.

So please tell me where I should put my code and variable count.

I'd post-process the web-server's access log.
 
G

GArlington

Hi All,

I am having a scenario in which I am having a full public website,
which won't require any login. I want to count the number of hits to
that website.

like :
1.
count = 0
if i hithttp://www.abc.com/xyz1.jspthen count should become 1
and if i hit onhttp://www.abc.com/xyz2.jspthen count should become 2
(I am writing these urls in the address bar and clicking enter)

2.
count=0
if I hithttp://www.abc.com/xyz1.jspthen count should become 1 and
then if I navigate tohttp://www.abc.com/xyz2.jspby clicking any
hyper link on xyz1.jsp file the count should remain 1

I this i don't want to put the code in every JSP. I need a common
place.

So please tell me where I should put my code and variable count.

Thanks in advance,
Tarun

I would suggest to allocate the session per user (as suggested by
"Abhijat Vatsyayan")
and then count for each request per session checking cgi var
"HTTP_REFERER", when the user follows the link this var will contain
the page where they come from, when the user types the address this
var will be empty...
 
J

John B. Matthews

Lew said:
Garg said:
basically this is a simple website without any authentication and
using JSP/Servlets. And why this problem happen is because sometimes
user copy the url and send it to anyone and that guy clicks that url
and the page is open. But in this condition i [sic] am not able to
increment
the count.
Tarun: Lew has proposed several excellent of ways to control access to
your web application that would preclude this problem. You cannot
"control access" and "not control access" at the same time.

The suggestions I gave were in the context of a web application written
without any authentication and using JSPs and servlets. Go back and review
them in light of that fact.

Reviewing...

Tarun: Lew is correct. It might have been clearer had I said, "control
navigation" rather than "control access", but the point is the same:
Even without authentication or for a deep link, you can control
navigation. Simply forward the request to your welcome page for a new
session. I understand you are in a hurry, but you must study the answers
you receive. Here are an excellent book and tutorial on the topic:

<http://pdf.coreservlets.com/>
<http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/>
 
S

shakah

[..snip...]
The best-designed web applications have a single point of entry and
all navigation within the site is via links. actually, via active
controls like "submit" buttons that are under the complete control of
the application.  With such a correct design, you can easily decide
what to count because the application controls all navigation.

[..snip...]

It's tough to categorize an approach which doesn't use hyperlinks
in a web application as "best-designed". It sounds like you're
bringing a desktop application mentality to web-based app design.
 
G

Garg

Tarun: Lew is correct. It might have been clearer had I said, "control
navigation" rather than "control access", but the point is the same:
Even without authentication or for a deep link, you can control
navigation. Simply forward the request to your welcome page for a new
session.

Thanks John for your input. But i can't implement this because it
needs a lot of code change.

servlet life cycle says that init or service method of the servlet
will be called whenever you call for the servlet. Can't i do something
so i can put a layer before init or service method and that layer will
increment the count or check any necessary thing like authentication
if i need to do that.
 
C

conrad

[..snip...]
The best-designed web applications have a single point of entry and
all navigation within the site is via links. actually, via active
controls like "submit" buttons that are under the complete control of
the application.  With such a correct design, you can easily decide
what to count because the application controls all navigation.

[..snip...]

It's tough to categorize an approach which doesn't use hyperlinks
in a web application as "best-designed". It sounds like you're
bringing a desktop application mentality to web-based app design.


Not at all. If you read up on the Model-View-Controller pattern, or
JSF, or Struts, or a host of other places you will find that, indeed,
the best-designed web apps never use hyperlinks for internal
navigation. It's not at all tough to categorize them that way when
you realize that hyperlinks would make the design much more chaotic
and bug-ridden, and the avoidance thereof makes for clean,
maintainable, robust, stable and extensible applications.

What's tough is to categorize the web apps that use hyperlinks
internally as anything but badly done.
 
C

conrad

Garg said:
Thanks John for your input. But i [sic] can't implement this because it
needs a lot of code change.

Awww, that's really tough.

That is a pitiful excuse for not doing necessary work. It might
justify delaying it, but it isn't a good reason to stop altogether.
It's especially bad if your application happens to be badly designed
(not that yours is, but if). The work necessary to fix the problem
will only get bigger and bigger, until finally the whole thing
collapses and you have to make the changes anyway, only by then it'll
be orders of magnitude harder.

It's also tough if you cannot deliver the desired functionality
without the code changes, and you won't make the changes because
they're too extensive. What do you do then?
servlet life cycle says that init or service method of the servlet
will be called whenever you call for the servlet. Can't i [sic] do something

Not quite. The 'init()' method is called when the servlet is loaded,
which might be once for many, many requests. The service() method is
just the doPost() and doGet() methods, in effect, so you're already
coding it.
so i [sic] can put a layer before init or service method and that layer will

Others have already suggested filters for you. Did you look into
that? It's pretty much just what you're describing. (Except of
course it only applies to the service() method, not the init()
method.)
increment the count or check any necessary thing like authentication
if i [sic] need to do that.

I thought you said this app didn't have authentication?

In any event, filters will be one way.

Do not be afraid to rewrite. If it's the quickest way forward, then a
slower way will not get you there faster.
 
J

Jean-Baptiste Nizet

(e-mail address removed) a écrit :
[..snip...]
The best-designed web applications have a single point of entry and
all navigation within the site is via links. actually, via active
controls like "submit" buttons that are under the complete control of
the application. With such a correct design, you can easily decide
what to count because the application controls all navigation.
[..snip...]

It's tough to categorize an approach which doesn't use hyperlinks
in a web application as "best-designed". It sounds like you're
bringing a desktop application mentality to web-based app design.


Not at all. If you read up on the Model-View-Controller pattern, or
JSF, or Struts, or a host of other places you will find that, indeed,
the best-designed web apps never use hyperlinks for internal
navigation. It's not at all tough to categorize them that way when
you realize that hyperlinks would make the design much more chaotic
and bug-ridden, and the avoidance thereof makes for clean,
maintainable, robust, stable and extensible applications.

What's tough is to categorize the web apps that use hyperlinks
internally as anything but badly done.

Oh come on! Sorry, but you need to read more on MVC in the context of
web apps. An application that doesn't use HTML correctly, tries to
simulate hyperlinks with buttons, and makes your webapp look like a
Swing app IS what can be called as a bad web application. Hyperlinks are
what makes the web, and not using them is a very bad idea. Hyperlinks
may have parameters. Hyperlinks are part of any well-designed MVC
application which, to the user, should most of the time behave like any
web site: be able to have links, to open in new tabs or windows, to
bookmark pages and to send URLs to friends.
Using hyperlinks doesn't mean that all requests don't go through the
central point of access. I completely agree with Shakah: you're
bringing a desktop application mentality to web-based app design.

http://struts.apache.org/1.2.x/userGuide/struts-html.html#link
http://struts.apache.org/2.0.11.1/docs/url.html
http://stripes.sourceforge.net/docs/current/taglib/stripes/link.html

JB.
 
C

conrad

Jean-Baptiste Nizet said:
Oh come on! Sorry, but you need to read more on MVC in the context of
web apps. An application that doesn't use HTML correctly, tries to

Oh, yes, I need to do that. I've written over a dozen of these apps,
and read much on it. I hold my knowledge up against any standard you
like on this matter.

Just because I disagree with you doesn't mean that I'm ill read.
simulate hyperlinks with buttons, and makes your webapp look like a
Swing app IS what can be called as a bad web application. Hyperlinks are

"can be called" - sure, you can call anything anything. But it isn't
a bad web application, because using POST instead of links has
advantages, specific to web apps.

And you guys keep talking about "having a desktop [or Swing]
mentality" like that is some sort of criticism. How is that a bad
thing, and how is what I'm doing that?

And even more important, just what do you mean by "a desktop
'mentality'"?
what makes the web, and not using them is a very bad idea. Hyperlinks
may have parameters. Hyperlinks are part of any well-designed MVC

Not for internal links, no they are not.
application which, to the user, should most of the time behave like any
web site: be able to have links, to open in new tabs or windows, to
bookmark pages and to send URLs to friends.

Not if you want to restrict those URLs, and control the application
experience. Doing those things can be undesirable.
Using hyperlinks doesn't mean that all requests don't go through the
central point of access. I completely agree with Shakah: you're
bringing a desktop application mentality to web-based app design.

There's that "mentality" word. How about defining what you mean by
that?

POSTs, as are commonly done internally in good web apps instead of
hyperlinks, allow the tramsmission of data also. They avoid a round-
trip to the browser to forward to the next page, on account of
forwards are server side, unlike links. The POST technique allows
precise control of application state, and keeps the user from entering
screens for which the preconditions have not been met. There is
nothing in that design approach that precludes links to well-defined
screens, but such links will always lack the sort of contextual
information for which the OP was asking (distinguish internal
navigation from external).

If these benefits constitute a "desktop application mentality" then
that must be a good thing.
 
S

shakah

On Jul 1, 6:22 pm, (e-mail address removed) wrote:
[...snip...]
POSTs, as are commonly done internally in good web apps instead of
hyperlinks, allow the tramsmission of data also. They avoid a round-
trip to the browser to forward to the next page, on account of
forwards are server side, unlike links. The POST technique allows
precise control of application state, and keeps the user from entering
screens for which the preconditions have not been met. There is
nothing in that design approach that precludes links to well-defined
screens, but such links will always lack the sort of contextual
information for which the OP was asking (distinguish internal
navigation from external).

Not sure about your first two sentences there, but in any case...

By "internal navigation from external", do you mean "authenticated"
versus "unauthenticated" state? Isn't that commonly (and simply)
handled
in webapps via sessions (i.e. cookies)?
 
J

Jean-Baptiste Nizet

Jean-Baptiste Nizet said:
Oh come on! Sorry, but you need to read more on MVC in the context of
web apps. An application that doesn't use HTML correctly, tries to

Oh, yes, I need to do that. I've written over a dozen of these apps,
and read much on it. I hold my knowledge up against any standard you
like on this matter.

Just because I disagree with you doesn't mean that I'm ill read.
simulate hyperlinks with buttons, and makes your webapp look like a
Swing app IS what can be called as a bad web application. Hyperlinks are

"can be called" - sure, you can call anything anything. But it isn't
a bad web application, because using POST instead of links has
advantages, specific to web apps.

And you guys keep talking about "having a desktop [or Swing]
mentality" like that is some sort of criticism. How is that a bad
thing, and how is what I'm doing that?

And even more important, just what do you mean by "a desktop
'mentality'"?

The web has its rules and idioms, and web design is not the same as
rich application design. Webapps are usually more open, indexable,
bookmarkable, linkable. If you do everything with POSTs, good luck
with that. And go explain your customer that your webapp apears at the
56784th position when doing a Google search, because Google is not
able to index your web app and nobody links to it.

HTTP is a standard as well, and GETs are supposed to be used for
requests that don't modify the server state (navigate to a page,
consult items in a repository, search, etc.). POSTs are supposed to be
used to modify state, and not for everything else. You choose not to
respect the standard and that's your right, but it's also the sign of
bad design (as IE has always be considered as a bad browser by techies
because it doesn't respect the HTML and CSS standards, which doesn't
mean it doesn't work or do something useful).
Not for internal links, no they are not.

Maybe you should teach Google, Ebay, Amazon, Slashdot, Yahoo and so on
how to design webapps, because I see many many hyperlinks in their
apps. And they're pretty successful.
Not if you want to restrict those URLs, and control the application
experience. Doing those things can be undesirable.

It can be undesirable. Most of the time, it IS desirable. That's what
users expect from web apps. Would you like it if Ebay, Google or Yahoo
didn't let you open several tabs in their webapp?
There's that "mentality" word. How about defining what you mean by
that?

POSTs, as are commonly done internally in good web apps instead of
hyperlinks, allow the tramsmission of data also. They avoid a round-
trip to the browser to forward to the next page, on account of
forwards are server side, unlike links.

How would a GET need additional round-trip to the server just to go to
another internal page or search through a repository? How are your
users supposed to refresh a page or use their back button when using
your POST-only webapp. Oh, they are not supposed to do that? So your
webapp doesn't work well with the most-used browser buttons? That's
what I call a bad webapp.

The POST technique allows
precise control of application state, and keeps the user from entering
screens for which the preconditions have not been met.

How so? A POST carries information to the server just as a GET does
it: through request parameters. They're just not visible in the
address bar. Except for transmitting a large amount of information,
what can be done by a POST that can't be done by a GET? If you rely on
the fact that POSTs are used to be sure that preconditions are met,
then you have a problem. Preconditions must be verified by your server-
side code. HTTP is stateless, and a POST request is not more difficult
to do than a GET for any script kiddie. Whether your action is being
called through a GET or through a POST, you have to check your
preconditions, because a good webapp *always* checks what comes from
the browser.

There is
nothing in that design approach that precludes links to well-defined
screens, but such links will always lack the sort of contextual
information for which the OP was asking (distinguish internal
navigation from external).

No. You may add a parameter to a hyperlink just as you add a parameter
to your POST request. Doing everything by POST just makes it much more
difficult to link to your webapp from the outside. That's what I call
"desktop application mentality". The web is about hyperlinks between
pages around the world. Your webapp will tend to be an insulated
island in the web, that nobody can link to. Just as if your
application was a desktop app.

JB.
 
C

conrad

Jean-Baptiste Nizet said:
The web has its rules and idioms, and web design is not the same as
rich application design. Webapps are usually more open, indexable,
bookmarkable, linkable. If you do everything with POSTs, good luck
with that. And go explain your customer that your webapp apears at the
56784th position when doing a Google search, because Google is not
able to index your web app and nobody links to it.

Right, like the web couldn't see the app just because it controls its
internal navigation. Every hit to that site is still a hit to that
site, just not necessarily to certain pages within it.

As I stated upthread, there is nothing in what I suggest to preclude
opening up certain URLs in the app to direct access. Your argument
here does not refute what I suggested.
HTTP is a standard as well, and GETs are supposed to be used for
requests that don't modify the server state (navigate to a page,
consult items in a repository, search, etc.). POSTs are supposed to be
used to modify state, and not for everything else. You choose not to
respect the standard and that's your right, but it's also the sign of

Huh? Who says the POSTs I suggest do not affect program state? In
general, they likely do.
bad design (as IE has always be considered as a bad browser by techies
because it doesn't respect the HTML and CSS standards, which doesn't
mean it doesn't work or do something useful).

Not related to my points.
Maybe you should teach Google, Ebay, Amazon, Slashdot, Yahoo and so on
how to design webapps, because I see many many hyperlinks in their
apps. And they're pretty successful.

Maybe you should teach Sun and others who do what I suggest, and teach
what I suggest, how to redesign their sites not to use the principles
I describe. They're pretty successful, too.
It can be undesirable. Most of the time, it IS desirable. That's what

"Most" of the time? How are you deriving that statistic?
users expect from web apps. Would you like it if Ebay, Google or Yahoo
didn't let you open several tabs in their webapp?

Nothing I suggest prevents opening tabs in the web app.

How would a GET need additional round-trip to the server just to go to
another internal page or search through a repository? How are your

You're right here.
users supposed to refresh a page or use their back button when using
your POST-only webapp. Oh, they are not supposed to do that? So your

Huh? None of the apps I've written or seen that follow the pattern I
suggest have trouble with back button or refresh. I don't get your
argument here.

Of course they're supposed to use those controls. I would never stop
them.
webapp doesn't work well with the most-used browser buttons? That's
what I call a bad webapp.

If you were right I would agree with you, but you're wrong. Web apps
that follow what I suggest have no trouble at all with those buttons.
Plpppt.
How so? A POST carries information to the server just as a GET does
it: through request parameters. They're just not visible in the

Actually, I was wrong to limit it to POST. It's sessions that hold
that information.
Preconditions must be verified by your server-
side code. HTTP is stateless, and a POST request is not more difficult
to do than a GET for any script kiddie. Whether your action is being
called through a GET or through a POST, you have to check your
preconditions, because a good webapp *always* checks what comes from
the browser.

Right again.
No. You may add a parameter to a hyperlink just as you add a parameter
to your POST request. Doing everything by POST just makes it much more
difficult to link to your webapp from the outside. That's what I call
Nonsense.

"desktop application mentality". The web is about hyperlinks between
pages around the world. Your webapp will tend to be an insulated
island in the web, that nobody can link to. Just as if your
application was a desktop app.

Nonsense. Nothing in what I suggest blocks the outside world from
linking to the app. Bogus argument.
 
J

Jean-Baptiste Nizet

(e-mail address removed) a écrit :
Right, like the web couldn't see the app just because it controls its
internal navigation. Every hit to that site is still a hit to that
site, just not necessarily to certain pages within it.

As I stated upthread, there is nothing in what I suggest to preclude
opening up certain URLs in the app to direct access. Your argument
here does not refute what I suggested.

So, all the internal navigation is done with POSTs, but links from the
outside to the webapp is done via GET. How is the outside world supposed
to discover your hidden entry points?
Huh? Who says the POSTs I suggest do not affect program state? In
general, they likely do.

You're then doing one of those ultra-rare applications where everything
the user does changes the state of the data. Most of the time, webapps
are a bunch of CRUD use-cases where most of the traffic consists in
searches and consultations, and a small fraction consists in creations,
updates and deletes. Users read many blogs, but don't post comments
often. Users search and consult many products before potentially buying
one.
Not related to my points.


Maybe you should teach Sun and others who do what I suggest, and teach
what I suggest, how to redesign their sites not to use the principles
I describe. They're pretty successful, too.

Huh. Look at http://bugs.sun.com/. The search form uses GET. And all the
links below the form look like internal hyperlinks to me.
See http://bugs.sun.com/top25_bugs.do. All the bugs are accessible
through hyperlinks.
"Most" of the time? How are you deriving that statistic?

From common sense. To be successful, webapps must be known by users. To
be known by users, they must be accessible by search engines, and linked
to by happy users to spread the hype. Search engines follow hyperlinks,
but don't submit forms or click on form buttons. Do you open a blog to
be read by nobody? Do you open a shop to sell goods to nobody?
Nothing I suggest prevents opening tabs in the web app.

Explain me how a user is supposed to open a page in a new tab or window
when all he has to navigate is buttons? Browsers only allow opening in
new tabs or windows with hyperlinks.
You're right here.


Huh? None of the apps I've written or seen that follow the pattern I
suggest have trouble with back button or refresh. I don't get your
argument here.

- Go to
http://volume1.coreservlets.com/archive/Form-Processing/form-data/ShowParametersPostForm.html
- Submit the form (a simple post-base example form)
- Try refreshing the page using your browser's refresh button. On
Firefox, I get this ugly dialog box (translated from French): To display
this page, the information which has been transmitted by Firefox must be
resent. This will repeat any action (like a search or a shop order)
previously done. Hence the redirect-after-post pattern (aka
Post-Redirect-Get) used by good webapps.
Of course they're supposed to use those controls. I would never stop
them.


If you were right I would agree with you, but you're wrong. Web apps
that follow what I suggest have no trouble at all with those buttons.
Plpppt.

So you never had this dialog box I just showed you? And you never had
browser warnings about information which must be resubmitted to get to
the a page in your back history? You must be living in a parallel world,
or not use IE nor Firefox.
Actually, I was wrong to limit it to POST. It's sessions that hold
that information.

I don't understand. If it's sessions that holds your precious
information, why would it be accessible only if you use POSTs? The
session is tracked by cookies or by URL-rewriting, and both techniques
work with hyperlinks.
Right again.


Nonsense.

If all the products sold by ebay weren't accessible via simple URLs,
Ebay wouldn't be what it is.
If the search results of google weren't accessible by a simple URL,
Google wouldn't exist anymore.
If all the articles of ZDNet, Slashdot or whatever weren't accessible
via a simple URL, they wouldn't earn any money. Linking to the welcome
page of your webapp isn't sufficient.
Nonsense. Nothing in what I suggest blocks the outside world from
linking to the app. Bogus argument.

How is a link supposed to work if all your application accepts is POST
requests from buttons. Could you explain us? Hyperlinks generate GET
requests.
 
C

conrad

Huh. Look athttp://bugs.sun.com/. The search form uses GET. And all the
links below the form look like internal hyperlinks to me.
Seehttp://bugs.sun.com/top25_bugs.do. All the bugs are accessible
through hyperlinks.

I didn't say Sun didn't use hyperlinks, I said they used these other
principles to good effect.


- Go tohttp://volume1.coreservlets.com/archive/Form-Processing/form-data/Sho...
- Submit the form (a simple post-base example form)
- Try refreshing the page using your browser's refresh button. On
Firefox, I get this ugly dialog box (translated from French): To display
this page, the information which has been transmitted by Firefox must be
resent. This will repeat any action (like a search or a shop order)
previously done.

No, it won't. Not if the web app is designed with idempotent
transactions, as of course, it should be. Repeating the action would
be a bug.

Don't use a bug as an argument against a technique. Argue against the
technique as it would be used with the bug fixed.
Hence the redirect-after-post pattern (aka
Post-Redirect-Get) used by good webapps.

Hence no need for that.

So you never had this dialog box I just showed you? And you never had
browser warnings about information which must be resubmitted to get to
the a page in your back history? You must be living in a parallel world,
or not use IE nor Firefox.

It's not a big issue. You hit "OK" and the screen refreshes. What's
the big deal?

Jean-Baptiste Nizet said:
I don't understand. If it's sessions that holds your precious
information, why would it be accessible only if you use POSTs? The

What part of "I was wrong" did you not understand?
session is tracked by cookies or by URL-rewriting, and both techniques
work with hyperlinks.

Not in the explicit sense of which I was speaking. Also, don't forget
that I am not against hyperlinks, just the indiscriminate use thereof
for internal navigation.

If all the products sold by ebay weren't accessible via simple URLs,
Ebay wouldn't be what it is.
If the search results of google weren't accessible by a simple URL,
Google wouldn't exist anymore.
If all the articles of ZDNet, Slashdot or whatever weren't accessible
via a simple URL, they wouldn't earn any money. Linking to the welcome
page of your webapp isn't sufficient.

Once again, I am not against all use of hyperlinks. Obviously you
have identified use cases where the web app opens up certain URLs. I
do not speak against that. I have stated many times in this thread
that web apps can open up certain URLs.
How is a link supposed to work if all your application accepts is POST
requests from buttons. Could you explain us? Hyperlinks generate GET
requests.

It would not be all the app accepts. Allow me to moderate my position
to say that such things must be done thoughtfully.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top