Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-25046

Cookie header too long, causing a 413 HTTP error

    Details

    • Similar Issues:
    • Released As:
      Jenkins 2.184

      Description

      Each time Jenkins (re)starts, its session-cookie name changes (ie JSESSIONID.some_random_string).

      After a while, the browser have a bunch of session cookies, each one having a different name, causing the "Cookie" request header to be very long. The server returns a HTTP 413 response and a blank page. The user must clean his cookies in order to access Jenkins again.

       

      Workaround: Since Jenkins 2.66 there are custom options for managing Jetty session IDs: https://github.com/jenkinsci/extras-executable-war/#jetty-session-ids

        Attachments

          Issue Links

            Activity

            Hide
            ssbarnea Sorin Sbarnea added a comment -

            The random session generation seems like a really bad design decision. Why not using Jenkins URL as base for a hash function. That's clearly unique per instance, doesn't change often and survives any number of restarts.

            Show
            ssbarnea Sorin Sbarnea added a comment - The random session generation seems like a really bad design decision. Why not using Jenkins URL as base for a hash function. That's clearly unique per instance, doesn't change often and survives any number of restarts.
            Hide
            danielbeck Daniel Beck added a comment -

            Why not using Jenkins URL as base for a hash function

            The session ID is set in a component that is independent from Jenkins and knows nothing about it, when the configured URL is not yet even known, and the configured URL can change at any time (in fact, it will change for every initially configured Jenkins instance). There are so many problems here.

            Although I suppose "All sessions are invalidated when I change the Jenkins URL" would make a fun bug report.

            Show
            danielbeck Daniel Beck added a comment - Why not using Jenkins URL as base for a hash function The session ID is set in a component that is independent from Jenkins and knows nothing about it, when the configured URL is not yet even known, and the configured URL can change at any time (in fact, it will change for every initially configured Jenkins instance). There are so many problems here. Although I suppose "All sessions are invalidated when I change the Jenkins URL" would make a fun bug report.
            Hide
            ssbarnea Sorin Sbarnea added a comment -

            Well, in this case the solution is to save this generated ID in the working directory and always re-use them if found. I doubt anyone would be able to run multiple Jenkins instances from the same working-directory.

            Show
            ssbarnea Sorin Sbarnea added a comment - Well, in this case the solution is to save this generated ID in the working directory and always re-use them if found. I doubt anyone would be able to run multiple Jenkins instances from the same working-directory.
            Hide
            yixiaol Yixiao Lin added a comment -

            Bump this issue.

            We use Jenkins enterprise and use the operation center to manage the masters.

            With more masters, we run into this issue quite frequently. 

            Show
            yixiaol Yixiao Lin added a comment - Bump this issue. We use Jenkins enterprise and use the operation center to manage the masters. With more masters, we run into this issue quite frequently. 
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            https://github.com/jenkinsci/jenkins/pull/3939 was integrated and released in 2.184. I marked it as the LTS candidate, but I am not sure it will be considered for backporting by Oliver Gondža talking the rebase issues in the pull request. Whomever is interested, please feel free to suggest a clean pull request against the LTS branch

             

            Show
            oleg_nenashev Oleg Nenashev added a comment - https://github.com/jenkinsci/jenkins/pull/3939  was integrated and released in 2.184. I marked it as the LTS candidate, but I am not sure it will be considered for backporting by Oliver Gondža talking the rebase issues in the pull request. Whomever is interested, please feel free to suggest a clean pull request against the LTS branch  

              People

              • Assignee:
                jsoref Josh Soref
                Reporter:
                ericcitaire Eric Citaire
              • Votes:
                39 Vote for this issue
                Watchers:
                40 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: