Uploaded image for project: 'JIRA (including JIRA Core)'
  1. JIRA (including JIRA Core)
  2. JRA-16021

Form data lost when using back button on HTTPS site

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Web interface
    • Labels:

      Description

      The Cache-Control settings for JIRA prevent the back button working on sites using HTTPS (like this one):

      Cache-Control: no-cache, no-store, must-revalidate
      

      The proper cache settings to use are the ones used by Confluence for the same purpose:

      Cache-Control: no-cache, must-revalidate
      

      See Chris Owen's blog post on this topic from 2007 for more information.

        Attachments

          Issue Links

            Activity

            blane Brian Lane created issue -
            blane Brian Lane made changes -
            Field Original Value New Value
            Link This issue is related to JRA-14031 [ JRA-14031 ]
            Hide
            blane Brian Lane added a comment -

            For reference we have Chris's internal blog about changes here - and I also found this blog that describes some of the issues as well.

            http://blog.pluron.com/2008/07/why-you-should.html

            Show
            blane Brian Lane added a comment - For reference we have Chris's internal blog about changes here - and I also found this blog that describes some of the issues as well. http://blog.pluron.com/2008/07/why-you-should.html
            blane Brian Lane made changes -
            Workflow jira [ 148367 ] Feature Request Workflow [ 162451 ]
            Hide
            anton@atlassian.com Anton Mazkovoi [Atlassian] added a comment - - edited

            One thing to note if we decide to go with removing "no-store" from the caching headers is that this could be a problem if there is JavaScript on the page that ran and modified the DOM of the page.

            As far as I can tell based on what I have been hearing from different people (handling different bugs and support cases), when returning back to the page (pressing the browser back button) some browsers show the last version of the DOM, i.e. the DOM that was the result of JavaScript running and modifying the original HTML. Other browsers show the original HTML. The trouble is that depending of what JavaScript did, we may want one behaviour or the other.

            For example, if the JavaScript disbaled a button on the page to prevent double submit, and the browser shows the last version of the DOM, the button will be disabled and cannot be pressed again. Which is not what we want. If the JavaScript moved an element from one place to another (e.g. drag-n-drop was performed) and original HTML is shown instread, this is not what we want either.

            I believe we do not have control on page per page basis of what the browser should do.

            We need to investigate the above problems (well, first prove their existence) before we make these changes.

            But at the moment it seems like removing "no-store" will have edge cases that we cannot fix.

            Show
            anton@atlassian.com Anton Mazkovoi [Atlassian] added a comment - - edited One thing to note if we decide to go with removing "no-store" from the caching headers is that this could be a problem if there is JavaScript on the page that ran and modified the DOM of the page. As far as I can tell based on what I have been hearing from different people (handling different bugs and support cases), when returning back to the page (pressing the browser back button) some browsers show the last version of the DOM, i.e. the DOM that was the result of JavaScript running and modifying the original HTML. Other browsers show the original HTML. The trouble is that depending of what JavaScript did, we may want one behaviour or the other. For example, if the JavaScript disbaled a button on the page to prevent double submit, and the browser shows the last version of the DOM, the button will be disabled and cannot be pressed again. Which is not what we want. If the JavaScript moved an element from one place to another (e.g. drag-n-drop was performed) and original HTML is shown instread, this is not what we want either. I believe we do not have control on page per page basis of what the browser should do. We need to investigate the above problems (well, first prove their existence) before we make these changes. But at the moment it seems like removing "no-store" will have edge cases that we cannot fix.
            anton@atlassian.com Anton Mazkovoi [Atlassian] made changes -
            Fix Version/s 4.1 [ 14244 ]
            Fix Version/s 4.0 [ 14091 ]
            wseliga Wojciech Seliga made changes -
            Assignee Wojciech Seliga [Atlassian] [ wseliga ]
            wseliga Wojciech Seliga made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            wseliga Wojciech Seliga made changes -
            Status In Progress [ 3 ] Open [ 1 ]
            wseliga Wojciech Seliga made changes -
            Assignee Wojciech Seliga [Atlassian] [ wseliga ]
            edwin@atlassian.com Edwin Wong [Atlassian] made changes -
            Labels 4_1
            edwin@atlassian.com Edwin Wong [Atlassian] made changes -
            Fix Version/s 4.1 [ 14244 ]
            chris@atlassian.com Chris Mountford made changes -
            Priority Blocker [ 1 ] Major [ 3 ]
            rkrishna Roy Krishna [Atlassian] made changes -
            Workflow Feature Request Workflow [ 162451 ] PM Feature Request Workflow [ 227871 ]
            Hide
            matt@atlassian.com Matt Ryall added a comment -

            The back button is not working properly on HTTPS on JAC at the moment, and I just lost yet another comment. I think this should be recategorised as a bug, because it's the same problem as JRA-14031.

            We've been running Confluence with 'Cache-Control: no-cache, must-revalidate' for several years now with no negative effects. In our experience, the problem Anton is talking about hasn't been a problem at all. The main reason you want need the back button to work is so that you can get back to your data when the server goes down or doesn't respond.

            Show
            matt@atlassian.com Matt Ryall added a comment - The back button is not working properly on HTTPS on JAC at the moment, and I just lost yet another comment. I think this should be recategorised as a bug, because it's the same problem as JRA-14031 . We've been running Confluence with 'Cache-Control: no-cache, must-revalidate' for several years now with no negative effects. In our experience, the problem Anton is talking about hasn't been a problem at all. The main reason you want need the back button to work is so that you can get back to your data when the server goes down or doesn't respond.
            matt@atlassian.com Matt Ryall made changes -
            Summary HTTPS cache header settings Form data lost when using back button on HTTPS site
            Description Conf 3 is doing some html changes to improve performance when being used with HTTPS.

            We should review these changes and look to add them to JIRA 4 as well.


            The Cache-Control settings for JIRA prevent the back button working on sites using HTTPS (like this one):

            {noformat}
            Cache-Control: no-cache, no-store, must-revalidate
            {noformat}

            The proper cache settings to use are the ones used by Confluence for the same purpose:

            {noformat}
            Cache-Control: no-cache, must-revalidate
            {noformat}

            See [Chris Owen's blog post|http://blogs.atlassian.com/developer/2007/12/cachecontrol_nostore_considere.html] on this topic from 2007 for more information.
            Component/s Web interface [ 10126 ]
            matt@atlassian.com Matt Ryall made changes -
            Issue Type Improvement [ 4 ] Bug [ 1 ]
            Workflow PM Feature Request Workflow [ 227871 ] JIRA Bug Workflow w Kanban v5 [ 341452 ]
            mlassau Mark Lassau [Atlassian] made changes -
            Component/s Performance [ 10660 ]
            ohernandez@atlassian.com Oswaldo Hernandez [Atlassian] Bugmaster made changes -
            Workflow JIRA Bug Workflow w Kanban v5 [ 341452 ] JIRA Bug Workflow w Kanban v6 [ 661530 ]
            ohernandez@atlassian.com Oswaldo Hernandez [Atlassian] Bugmaster made changes -
            Workflow JIRA Bug Workflow w Kanban v5 [ 661530 ] JIRA Bug Workflow w Kanban v6 [ 672673 ]

              People

              • Assignee:
                Unassigned
                Reporter:
                blane Brian Lane
              • Votes:
                8 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated: