Euphoria
Ticket #366:
base64 encode/decode
-
Reported by
jeremy
Nov 11, 2010
Needed for various HTTP POST uploading/decoding
Details
1. Comment by jimcbrown
Nov 11, 2010
Implementation based on http://www.RapidEuphoria.com/b64.zip by Pete Lomax.
2. Comment by ne1uno
Nov 11, 2010
you committed to
branches/1913-fixes/base64.e
branches/1913-fixes/t_base64.e
is this a new testing branch?
where does it belong? std/net std/code/ std/
3. Comment by jimcbrown
Nov 11, 2010
They should be include/std/base64.e and tests/t_base64.e
They should have been committed to trunk, however there is the matter of bugfixes-only after a RC. This is confusing since the related ticket:367 ticket:367 is slated for 4.0.0RC2 while this one is slated for 4.1.0 but the implementation required to fix http_post() (which we have to fix since it made it to RC) depends on having base64 encoding/decoding.
4. Comment by jeremy
Nov 11, 2010
We could do http_post() w/multi-part encoding w/o base64 technically. If doing a file upload (which is the most common reason for using multi-part post) then the user would have to supply the file contents as base64 encoded their selves. So, it offloads it to the user. This wasn't what I wanted originally.
So, there are two solutions I can think of:
- Consider the lack of base64 as a bug and add it
- Implement multi-part post w/o base64 and let the user fend for themselves and in 4.1 add a base64 implementation and update multi-part post to do base64 stuff internally. We should be able to do it in a manner that doesn't affect backward compatibility
5. Comment by jeremy
Nov 12, 2010
Moved to OnHold. It's not really in trunk yet, so it's not really fixed. May be moved to trunk soon or later depending on decisions so the ticket needs to remain open until we are 100% done.
6. Comment by mattlewis
Nov 12, 2010
The multipart_form_data_encode() is certainly buggy as-is. We obviously never tested this capability. I don't think this is unreasonable to implement for RC2. It's really not adding new functionality, since the stub has been there.
7. Comment by jimcbrown
Nov 12, 2010
After much thinking, I've unilatertally decided to bump this ticket up to 4.0.0RC2
Adding a new include is a small change, and not a breaking one. The real problem is if we decide we need to make a breaking change to the lib or remove it entirely later. However, either of these options would likely cause http_post() to have the same problem, and http_post() is already set in stone in RC1.
8. Comment by jimcbrown
Nov 13, 2010
Jeremy appears to have gotten this working, as ticket:367 is closed out.
GitHub