Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #9016 (closed enhancement: wontfix)

Opened 1 year ago

Last modified 1 year ago

[PATCH] automatic decoding of base64-encoded file uploads

Reported by: bgreenlee Assigned to: core
Priority: normal Milestone: 1.x
Component: ActiveRecord Version: edge
Severity: normal Keywords: tiny
Cc:

Description

This patches ActionController::AbstractRequest.read_multipart to decode base64-encoded file uploads. Currently, the Content-Transfer-Encoding of a file is ignored completely, so base64-encoded files are not decoded.

Attachments

base64_multipart_decoding.diff (2.2 kB) - added by bgreenlee on 07/19/07 06:34:04.
Less brain-dead check for base64 Content-Transfer-Encoding

Change History

07/19/07 06:07:01 changed by bgreenlee

  • type changed from defect to enhancement.

07/19/07 06:13:07 changed by manfred

Looks good. +1 for inclusion.

07/19/07 06:34:04 changed by bgreenlee

  • attachment base64_multipart_decoding.diff added.

Less brain-dead check for base64 Content-Transfer-Encoding

07/19/07 06:45:49 changed by codahale

+1

07/19/07 06:46:34 changed by codahale

  • keywords set to tiny.

07/19/07 08:39:27 changed by lifofifo

-1

Isn't this against http rfc as per http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.5 ? I just had a quick look at it, please correct me if I'm wrong.

Thanks.

07/19/07 09:25:05 changed by mpalmer

Wow lifofifo, I'm not going to ask how you knew that was in the RFC, but I think you're right.

"HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client."

There's some extra stuff in the RFC that pertains, but that MUST is pretty clear -- thou shalt not use Content-Transfer-Encoding in HTTP MIME messages.

19.4 says "HTTP has a few features that are different from those described in RFC 2045. These differences were carefully chosen to optimize performance over binary connections ..." which gives a pretty good rationale for the change -- HTTP never needs base64 encoding, it's very wasteful of network resources, and so it's out on it's ear.

I'm not sure where that leaves bgreenlee -- I suppose the functionality will have to be pushed up the application stack and the data decoded after it's been parsed out into the file. I don't actually think that's going to be a massive chunk of code, really.

The only ray of light might be an appeal based on section 19.3, which states, in part, "We therefore recommend that operational applications be tolerant of deviations whenever those deviations can be interpreted unambiguously." since the meaning and action of CTE header is unambiguous, but 19.4 is pretty compelling and clear-cut.

Sorry bgreenlee, but I'm going to have to -1 this, on the basis that it's in explicit contravention of RFC2616, and the application-level workaround doesn't seem like it should be too huge.

07/19/07 09:31:01 changed by manfred

I'm sorry, but in that case I'm going to retract my +1 too.

07/19/07 12:28:50 changed by bgreenlee

  • status changed from new to closed.
  • resolution set to wontfix.

Yep, you're right. Good catch. Bummer.