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

line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: In Progress (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
    • Environment:
      window senvironment, windows 2008 server
    • Similar Issues:

      Description

      When I submit using json the server responds with error 400, the same exact submittal with jenkins version 1.5.30 and below gives me a success. We looked at this some more and found this out .

      The root of this problem is a line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification. The HTTP RFC specifies \r\n (CRLF, (Windows line endings)) to be the line endings for HTTP. However, almost all servers also support \n (UNIX line endings). Invoking the Jenkins' HTTP API on a linux machine directly via the 'curl' command line tool is happy with the \n line-endings (which curl defaults to on linux). However, forcing curl to use \r\n as its line endings causes the transaction to fail using the same error code the obs.py fails with.

      Now, for the fun part (why we can't work around this easily) - We checked the underlying Python library httplib we use has \r\n hardcoded as that's what the HTTP specification calls for. There is no option to switch it to \n.

        Attachments

          Activity

          narayankamath Narayan Kamath created issue -
          narayankamath Narayan Kamath made changes -
          Field Original Value New Value
          Description When I submit using json the server responds with error 400, the same exact submittal with jenkins version 1.5.30 and below gives me a success. When I submit using json the server responds with error 400, the same exact submittal with jenkins version 1.5.30 and below gives me a success. We looked at this some more and found this out .

          The root of this problem is a line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification. The HTTP RFC specifies \r\n (CRLF, (Windows line endings)) to be the line endings for HTTP. However, almost all servers also support \n (UNIX line endings). Invoking the Jenkins' HTTP API on a linux machine directly via the 'curl' command line tool is happy with the \n line-endings (which curl defaults to on linux). However, forcing curl to use \r\n as its line endings causes the transaction to fail using the same error code the obs.py fails with.

          Now, for the fun part (why we can't work around this easily) - We checked the underlying Python library httplib we use has \r\n hardcoded as that's what the HTTP specification calls for. There is no option to switch it to \n.
          Summary Jenkins multipart form data submittal through Json is broken line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification
          aaronfitz Aaron Fitzgerald made changes -
          Component/s core [ 15593 ]
          Component/s parameterized-trigger [ 15592 ]
          Labels form-data jenkins multipart form-data http
          patchranger Dmitry Danilson made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          hshah Harsh Shah made changes -
          Link This issue is blocking JENKINS-11120 [ JENKINS-11120 ]
          hshah Harsh Shah made changes -
          Link This issue is blocking JENKINS-11120 [ JENKINS-11120 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 151998 ] JNJira + In-Review [ 185479 ]

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            narayankamath Narayan Kamath
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated: