[MPlayer-dev-eng] http stream basic auth base64_encode() fix

[Jeff D'Angelo]

On Tue, 28 Feb 2006, Reimar Döffinger wrote:

> Hi,
> On Tue, Feb 28, 2006 at 12:15:30PM -0500, Jeff D'Angelo wrote:
> > So that it conforms to RFC 2045:
> >
> > <http://jeffdangelo.org/patches/>
> > MPlayer-1.0pre7try2.http_basic_auth_base64_encode.patch
> > MPlayer-cvs-main-20060228.http_basic_auth_base64_encode.patch
>
> I would prefer this way of fixing it (see attached patch).

Thanks.  I'm all for suggestions for improvement :).

While I hope not to step on your toes, that also got me thinking a bit and
I made a couple observations:

1) At the cost of some indentation and using a different length
   calculation, you could move the memset() inside of the final }else{
   block just before the successful return statement.  Here the out chr
   ptr has already been advanced to just beyond the last regular base64
   encoded char and at the beginning of the pad.  This will avoid
   memset()ing some unnecessary '='s.

2) For username + ':' + password string lengths of 6, 9 or 12 or more, the
   attempt to set outMax at the end of the padding will actually extend
   the memset() '=' chars beyond the end of the pad; though it will save
   the main while() loop a couple of iterations before it find the input
   string is too long for the output.  A way to ensure only a max of 2 '='
   chars are used for the pad are to use the outLen count inside the final
   }else{ block.

   The enclosed patch file makes an attempt at doing both parts #1 and #2.
   This was included in the tests mentioned in the previous note.

3) However, the extra padding is cut off correctly by the proper return
   value and the implied calling function's responsibility of setting the
   terminating '\0'.  Arguably, you could just cut out line 673 of your
   patch and it should still work fine.

Just some thoughts.  All of these should work, and are tradeoffs in
complexity & speed.  Use whatever floats your boat.  I'm just happy this
is fixed :).

> > Tested successfully against an Icecast 2.2.0 server (Otto Audio Jukebox).
> >
> > Let me know if you need anything else.
>
> Yes, could you test the empty password case? You never know what the
> server might expect in that case *g*

I did as mentioned in my previous note.  Thanks for the suggestion.

-- 
Jeff

> Greetings,
> Reimar Döffinger
>
-------------- next part --------------
Index: http.c
===================================================================
RCS file: /cvsroot/mplayer/main/libmpdemux/http.c,v
retrieving revision 1.34
diff -u -r1.34 http.c
--- http.c	9 Feb 2006 14:07:57 -0000	1.34
+++ http.c	6 Mar 2006 16:31:58 -0000
@@ -659,7 +659,7 @@
 
 int 
 base64_encode(const void *enc, int encLen, char *out, int outMax) {
-	static const char	b64[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
+	static const char	b64[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
 
 	unsigned char		*encBuf;
 	int			outLen;
@@ -685,11 +685,10 @@
 			bits <<= 6 - shift;
 			shift = 6;
 		} else {
-			// Terminate with Mime style '='
-			*out = '=';
-			outLen++;
-
-			return outLen;
+			// Pad with 0 to 2 '=' chars as needed
+			if (outLen & 3)
+				memset(out, '=', 4 - (outLen & 3) );
+			return (outLen + 3) & ~3;
 		}
 
 		// Encode 6 bit segments