4 Replies Latest reply: Jun 9, 2006 12:54 AM by BKBK RSS

    Possible GetHttpRequestData() bug?

    BKBK Community Member
    BKBK Jun 8, 2006 7:05 AM
      Possible GetHttpRequestData()Bug:
      If you upload an image using the code below, the variable, GetHttpRequestData().content, will include header information at the beginning and at the end of the content. That is an error. It should not include anything else besides the raw binary data that the client submits, as that corrupts the image.

      To reproduce:
      1)Run the code, using your own paths, if necessary.

      2) Open the binary file, copiedPhoto.jpg, in a universal editor like EditPad, and you will see that it begins with header information

      -----------------------------7d63431aa0526
      Content-Disposition: form-data; name="FileContents"; filename="C:\CFusionMX7\wwwroot\uploadtest\myPhoto.jpg"
      Content-Type: image/pjpeg

      and ends with header information

      -----------------------------7d63431aa0526
      Content-Disposition: form-data; name="submit"

      Upload File
      -----------------------------7d63431aa0526--

      The result is that the image fails to render in any image viewer. If you delete the extraneous lines, and re-save the file as a JPG file, you will then be able to view the image.

      • 847 Views
      • Tags:
        • 1. Re: Possible GetHttpRequestData() bug?
          Mr Black Community Member
          Mr Black Jun 8, 2006 7:43 AM (in response to BKBK)
          I beleive this is by design. GetHttpRequestData() returns the body of HTTP request. In your case this is a mutipart-formatted request. So, the data are correct. You could (a) use CFFILE instead; (b) use normal (non-multipart) POST request; (c) analyze request headers, find part definitions, and remove part boundaries

          (b) could be difficult to implement on the client side, since <input type="file"... always generates multipart request.

          So, CFFILE approach looks like simplest and most straighforward.
          • 2. Re: Possible GetHttpRequestData() bug?
            BKBK Community Member
            BKBK Jun 8, 2006 9:03 AM (in response to Mr Black)
            CFFILE approach looks like simplest and most straighforward.
            Thanks Mr. Black. One intention was actually to find an alternative to cffile.

            I beleive this is by design. GetHttpRequestData() returns the body of HTTP request.
            I'm with you, so far.

            In your case this is a mutipart-formatted request. So, the data are correct.
            I disagree. By the same reasoning cffile should also upload the part boundaries of the request; it doesn't. Unless, of course, you're implying that cffile's attributes give it a certain degree of fine-tuning. Then again, the problem persists even if one adds the attribute accept="image/*" to the tag <input type="file">.

            The livedocs describe GetHttpRequestData().content as Raw content from form submitted by client, in string or binary format. However, the raw content that the client submits doesn't contain extraneous information about part boundaries. In effect, I'm suggesting the design be changed, if necessary, allowing the developer some control over the part boundaries.

            • 3. Re: Possible GetHttpRequestData() bug?
              Mr Black Community Member
              Mr Black Jun 8, 2006 11:34 AM (in response to BKBK)
              >cffile should also upload the part boundaries of the request;
              No. CFFILE ACTION="UPLOAD" does the body parsing for you and splits it into separate logical parts that may include several files and/or url-encoded data. You use CFFILE to access portions marked, as files. URL-encoded data available, as normal form variables. If CFFILE would just saved the content of the body, it would be useless. In fact, you may have several CFFILEs used for the same request.

              >raw content that the client submits doesn't contain extraneous information about part boundaries
              This is not true, according to your example. As I said already, if <INPUT TYPE="FILE" is used on client's HTML form, the browser will format HTTP request, as a multipart request, regardless of the number of elements of data to be sent. It means that even the client sends only one file, it still will be in a multipart format. This is by design.

              Of course, there could be special reasons why you want to avoid the use of CFFILE, but the amount of programming you need to accomplish and expected quality of results are clearly against this approach.
              • 4. Possible GetHttpRequestData() bug?
                BKBK Community Member
                BKBK Jun 9, 2006 12:54 AM (in response to Mr Black)
                >> raw content that the client submits doesn't contain extraneous
                >> information about part boundaries

                > This is not true, according to your example.
                It is. In my example, the "raw content" that the client submits is the content of the image binary.

                > As I said already, if <INPUT TYPE="FILE" is used on client's HTML form,
                > the browser will format HTTP request, as a multipart request, regardless
                > of the number of elements of data to be sent. It means that even the client
                > sends only one file, it still will be in a multipart format. This is by design.
                I agree. However true, this doesn't add to the subject.

                > CFFILE ACTION="UPLOAD" does the body parsing for you and splits it into
                > separate logical parts that may include several files and/or url-encoded data.
                That, indeed, is the kind functionality that I think should be added to or alongside the function, GetHttpRequestData().

                > You use CFFILE to access portions marked, as files. URL-encoded data available,
                > as normal form variables. If CFFILE would just saved the content of the body,
                > it would be useless. In fact, you may have several CFFILEs used for the same request.
                Quite. That is what I am saying about GetHttpRequestData().