counts the number of hit on a website containing many JSPs

Discussion in 'Java' started by Garg, Jun 30, 2008.

  1. Garg

    Garg Guest

    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
     
    Garg, Jun 30, 2008
    #1
    1. Advertising

  2. Garg

    Lew Guest

    Garg wrote:
    > 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.

    --
    Lew
     
    Lew, Jun 30, 2008
    #2
    1. Advertising

  3. Garg

    Garg Guest

    > 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
     
    Garg, Jun 30, 2008
    #3
  4. In article
    <>,
    Garg <> wrote:

    > > 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: 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.

    --
    John B. Matthews
    trashgod at gmail dot com
    home dot woh dot rr dot com slash jbmatthews
     
    John B. Matthews, Jun 30, 2008
    #4
  5. Garg wrote:
    > 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.
     
    Abhijat Vatsyayan, Jun 30, 2008
    #5
  6. Garg wrote:
    > 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.

    --
    RGB
     
    RedGrittyBrick, Jul 1, 2008
    #6
  7. Garg

    GArlington Guest

    On Jun 30, 6:33 pm, Garg <> wrote:
    > 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...
     
    GArlington, Jul 1, 2008
    #7
  8. In article <>,
    Lew <> wrote:

    > Garg wrote:
    > >> 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.

    >
    > John B. Matthews wrote:
    > > 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/>

    --
    John B. Matthews
    trashgod at gmail dot com
    home dot woh dot rr dot com slash jbmatthews
     
    John B. Matthews, Jul 1, 2008
    #8
  9. Garg

    shakah Guest

    On Jun 30, 2:30 pm, Lew <> wrote:

    [..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.
     
    shakah, Jul 1, 2008
    #9
  10. Garg

    Garg Guest


    > 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.
     
    Garg, Jul 1, 2008
    #10
  11. Garg

    Guest

    On Jul 1, 1:08 pm, shakah <> wrote:
    > On Jun 30, 2:30 pm, Lew <> wrote:
    >
    > [..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.

    --
    Lew
     
    , Jul 1, 2008
    #11
  12. Garg

    Guest

    Garg <> wrote:
    > 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.

    --
    Lew
     
    , Jul 1, 2008
    #12
  13. a écrit :
    > On Jul 1, 1:08 pm, shakah <> wrote:
    >> On Jun 30, 2:30 pm, Lew <> wrote:
    >>
    >> [..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.
     
    Jean-Baptiste Nizet, Jul 1, 2008
    #13
  14. Garg

    Guest

    Jean-Baptiste Nizet wrote:
    > 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.

    --
    Lew
     
    , Jul 1, 2008
    #14
  15. Garg

    shakah Guest

    On Jul 1, 6:22 pm, 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)?
     
    shakah, Jul 2, 2008
    #15
  16. Garg

    Roedy Green Guest

    On Mon, 30 Jun 2008 10:33:42 -0700 (PDT), Garg <>
    wrote, quoted or indirectly quoted someone who said :

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


    Look up the SSI facilities available.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Jul 2, 2008
    #16
  17. On 2 juil, 00:22, wrote:
    > Jean-Baptiste Nizet wrote:
    > > 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).

    > > 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.
    >


    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.

    > > 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.
    >


    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?

    > > 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.


    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.
     
    Jean-Baptiste Nizet, Jul 2, 2008
    #17
  18. Garg

    Guest

    Jean-Baptiste Nizet wrote:
    > 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.

    --
    Lew
     
    , Jul 2, 2008
    #18
  19. a écrit :
    > Jean-Baptiste Nizet wrote:
    >> 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.
    >


    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?

    >> 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.


    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.

    >
    >> 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.


    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.

    >
    >> It can be undesirable. Most of the time, it IS desirable. That's what

    >
    > "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?

    >> 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.
    >


    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.

    >
    >> 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.
    >


    - 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.
    >
    >> 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.


    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.

    >
    >> 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.


    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.

    >
    >> 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.


    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.

    >
    >> "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.
    >


    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.
     
    Jean-Baptiste Nizet, Jul 2, 2008
    #19
  20. Garg

    Guest

    Jean-Baptiste Nizet wrote:
    > >> The web has its rules and idioms, and web design is not the same as


    > 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?

    Lew wrote:
    > > Actually, I was wrong to limit it to POST.  It's sessions that hold
    > > that information.


    Jean-Baptiste Nizet wrote:
    > 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.

    --
    Lew
     
    , Jul 2, 2008
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?SmFtZXNT?=

    ASP.NET Worker Process Thread Counts

    =?Utf-8?B?SmFtZXNT?=, Apr 27, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    704
    =?Utf-8?B?SmFtZXNT?=
    Apr 27, 2005
  2. Mogga
    Replies:
    3
    Views:
    1,055
    Beauregard T. Shagnasty
    Nov 18, 2003
  3. CK
    Replies:
    9
    Views:
    425
    Jerry Rasmussen
    Oct 19, 2006
  4. Lee  Crawford

    Libraries in a WAR containing JSPs?

    Lee Crawford, Dec 29, 2006, in forum: Java
    Replies:
    1
    Views:
    307
  5. Michael McLaughlin

    Stupid newbie question re website hit counting

    Michael McLaughlin, Jul 22, 2003, in forum: Perl Misc
    Replies:
    2
    Views:
    143
    J. Gleixner
    Jul 22, 2003
Loading...

Share This Page