You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2008/04/26 10:58:30 UTC
Re: svn: MIME type 'text/x-c++' ends with non-alphanumeric
character
Thread moved to dev@
On Sat, Apr 26, 2008 at 10:24:45AM +0200, Alan Barrett wrote:
> On Fri, 25 Apr 2008, Andy Levy wrote:
> > On Fri, Apr 25, 2008 at 5:12 PM, Mark E. Hamilton <mh...@sandia.gov> wrote:
> > > $ svn propset --quiet svn:mime-type 'text/x-c++' --targets .svn_files
> > > svn: MIME type 'text/x-c++' ends with non-alphanumeric character
>
> If svn is complaining about that, I'd call it a bug. The syntax defined
> in RFC 1521 clearly says
>
> token := 1*<any (ASCII) CHAR except SPACE, CTLs,
> or tspecials>
>
> There's nothing about "must start and end with an alphanumeric character".
>
> > > 1. What is the correct mime-type for C++ files? Clearly 'text/plain' would
> > > suffice, but is there a more correct one?
> >
> > http://filext.com/file-extension/CPP shows several options:
>
> Sure, you could probably find something that works for whatever you
> want to do, and also works with svn. But you should be able to use
> "text/x-c++" without svn complaining. I suggest reporting this as a
> bug.
Would this be better?
Can anyone test if this breaks anything?
(There seem to be no mime-type-related unit tests...)
Index: subversion/libsvn_subr/validate.c
===================================================================
--- subversion/libsvn_subr/validate.c (revision 30791)
+++ subversion/libsvn_subr/validate.c (working copy)
@@ -41,6 +41,8 @@ svn_mime_type_validate(const char *mime_type, apr_
only looking at the media type here. */
const apr_size_t len = strcspn(mime_type, "; ");
const char *const slash_pos = strchr(mime_type, '/');
+ int i;
+ const char *tspecials = "()<>@,;:\\\"/[]?="; /* see RFC 1521 */
if (len == 0)
return svn_error_createf
@@ -52,10 +54,20 @@ svn_mime_type_validate(const char *mime_type, apr_
(SVN_ERR_BAD_MIME_TYPE, NULL,
_("MIME type '%s' does not contain '/'"), mime_type);
- if (! apr_isalnum(mime_type[len - 1]))
- return svn_error_createf
- (SVN_ERR_BAD_MIME_TYPE, NULL,
- _("MIME type '%s' ends with non-alphanumeric character"), mime_type);
+ /* RFC 1521 says:
+ * subtype := token ; case-insensitive
+ * token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials> */
+ for (i = 0; i < len; i++)
+ {
+ if (! apr_isascii(mime_type[i])
+ || apr_iscntrl(mime_type[i])
+ || apr_isspace(mime_type[i])
+ || strchr(tspecials, mime_type[i]) != NULL)
+ return svn_error_createf
+ (SVN_ERR_BAD_MIME_TYPE, NULL,
+ _("MIME type '%s' contains invalid character '%c'"),
+ mime_type, mime_type[i]);
+ }
return SVN_NO_ERROR;
}
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: [PATCH] validate MIME type correctly (was: Re: svn: MIME type
'text/x-c++' ends with non-alphanumeric) character
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Apr 26, 2008 at 02:44:47PM +0200, Alan Barrett wrote:
> On Sat, 26 Apr 2008, Stefan Sperling wrote:
> > > except I am not sure if you want to
> > > allow svn:mime_type="type/subtype ; parameter = value"
> >
> > The code explicitly allows this. I don't know whether this
> > is good/bad, but I don't think we should break this since
> > it's probably being used in the wild somewhere.
>
> Oh, I missed the fact that the new code was focused only on the
> type/subtype part of the string. I think it's good to allow semicolon
> and parameters, but I mistakenly thought that the code would deny them.
OK.
Patch passes make check, comitted in r30795.
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: [PATCH] validate MIME type correctly (was: Re: svn: MIME type
'text/x-c++' ends with non-alphanumeric) character
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 26 Apr 2008, Stefan Sperling wrote:
> > except I am not sure if you want to
> > allow svn:mime_type="type/subtype ; parameter = value"
>
> The code explicitly allows this. I don't know whether this
> is good/bad, but I don't think we should break this since
> it's probably being used in the wild somewhere.
Oh, I missed the fact that the new code was focused only on the
type/subtype part of the string. I think it's good to allow semicolon
and parameters, but I mistakenly thought that the code would deny them.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] validate MIME type correctly
Posted by Daniel Shahaf <d....@daniel.shahaf.co.il>.
Stefan Sperling wrote on Mon, 28 Apr 2008 at 19:51 +0200:
> On Mon, Apr 28, 2008 at 01:37:50PM -0400, Greg Hudson wrote:
> >
> > On Mon, 2008-04-28 at 19:18 +0200, Stefan Sperling wrote:
> > > > Stefan Sperling wrote on Mon, 28 Apr 2008 at 17:00 +0200:
> > > > > Btw, if there's any space before the semicolon (i.e. 'text/plain ;')
> > > > > trunk will now raise an error. RFC 1521 seems to agree with this:
> >
> > RFC 1521 has long been obsoleted by RFC 2045-2049, although that grammar
> > isn't materially different in 2045.
> >
> > RFC 822 takes a very a relaxed attitude towards whitespace:
> >
> > 3.1.4. STRUCTURED FIELD BODIES
> >
> > To aid in the creation and reading of structured fields, the
> > free insertion of linear-white-space (which permits folding
> > by inclusion of CRLFs) is allowed between lexical tokens.
> > Rather than obscuring the syntax specifications for these
> > structured fields with explicit syntax for this linear-white-
> > space, the existence of another "lexical" analyzer is assumed.
> >
> > RFC 1521 and 2045 are written in the same style. RFC 2822 (obsoleting
> > 822) cleans this up, but to my knowledge there is no cleaned-up grammar
> > for content-type headers.
>
> Wow, so many numbers. I wasn't aware of the status of RFC 1521,
> thanks for pointing this out!
>
> Anyway, looking at the code again, it seems my assumption that
> it could not deal with whitespace before the semicolon was wrong.
>
> This is how we determine the length of the media type in the mime type:
>
> const apr_size_t len = strcspn(mime_type, "; ")
>
> The declaration of strcspn is:
> size_t strcspn(const char *s, const char *charset)
>
> strcspn "computes the string array index in s of the first
> character of s which is also in charset". We should therefore
> stop counting characters at either ';' or ' '. So the case
> 'plain/text ;' should be handled correctly by the current code,
> for any amount of whitespace before the semicolon. It should be
> handled just as the case 'plain/text; ' is handled.
>
>
What about these? ---
' plain/text'
'plain /text'
'plain/ text'
Are they valid?
(Sorry; I like edge cases.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] validate MIME type correctly
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Apr 28, 2008 at 01:37:50PM -0400, Greg Hudson wrote:
>
> On Mon, 2008-04-28 at 19:18 +0200, Stefan Sperling wrote:
> > > Stefan Sperling wrote on Mon, 28 Apr 2008 at 17:00 +0200:
> > > > Btw, if there's any space before the semicolon (i.e. 'text/plain ;')
> > > > trunk will now raise an error. RFC 1521 seems to agree with this:
>
> RFC 1521 has long been obsoleted by RFC 2045-2049, although that grammar
> isn't materially different in 2045.
>
> RFC 822 takes a very a relaxed attitude towards whitespace:
>
> 3.1.4. STRUCTURED FIELD BODIES
>
> To aid in the creation and reading of structured fields, the
> free insertion of linear-white-space (which permits folding
> by inclusion of CRLFs) is allowed between lexical tokens.
> Rather than obscuring the syntax specifications for these
> structured fields with explicit syntax for this linear-white-
> space, the existence of another "lexical" analyzer is assumed.
>
> RFC 1521 and 2045 are written in the same style. RFC 2822 (obsoleting
> 822) cleans this up, but to my knowledge there is no cleaned-up grammar
> for content-type headers.
Wow, so many numbers. I wasn't aware of the status of RFC 1521,
thanks for pointing this out!
Anyway, looking at the code again, it seems my assumption that
it could not deal with whitespace before the semicolon was wrong.
This is how we determine the length of the media type in the mime type:
const apr_size_t len = strcspn(mime_type, "; ")
The declaration of strcspn is:
size_t strcspn(const char *s, const char *charset)
strcspn "computes the string array index in s of the first
character of s which is also in charset". We should therefore
stop counting characters at either ';' or ' '. So the case
'plain/text ;' should be handled correctly by the current code,
for any amount of whitespace before the semicolon. It should be
handled just as the case 'plain/text; ' is handled.
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: [PATCH] validate MIME type correctly
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2008-04-28 at 19:18 +0200, Stefan Sperling wrote:
> > Stefan Sperling wrote on Mon, 28 Apr 2008 at 17:00 +0200:
> > > Btw, if there's any space before the semicolon (i.e. 'text/plain ;')
> > > trunk will now raise an error. RFC 1521 seems to agree with this:
RFC 1521 has long been obsoleted by RFC 2045-2049, although that grammar
isn't materially different in 2045.
RFC 822 takes a very a relaxed attitude towards whitespace:
3.1.4. STRUCTURED FIELD BODIES
To aid in the creation and reading of structured fields, the
free insertion of linear-white-space (which permits folding
by inclusion of CRLFs) is allowed between lexical tokens.
Rather than obscuring the syntax specifications for these
structured fields with explicit syntax for this linear-white-
space, the existence of another "lexical" analyzer is assumed.
RFC 1521 and 2045 are written in the same style. RFC 2822 (obsoleting
822) cleans this up, but to my knowledge there is no cleaned-up grammar
for content-type headers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] validate MIME type correctly
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Apr 28, 2008 at 06:33:20PM +0300, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, 28 Apr 2008 at 17:00 +0200:
> > On Mon, Apr 28, 2008 at 10:31:58AM -0400, C. Michael Pilato wrote:
> > > $ svn pget svn:mime-type ~/projects/subversion/COMMITTERS
> > > text/plain; charset=UTF-8
> >
> > Btw, if there's any space before the semicolon (i.e. 'text/plain ;')
> > trunk will now raise an error. RFC 1521 seems to agree with this:
> >
> > content := "Content-Type" ":" type "/" subtype *(";" parameter)
> > subtype := token
> > token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
> >
> > But I hope we're not breaking anyone's setup.
> >
> >
>
> Why is a space allowed *after* the semicolon (as in cmpilato's example)?
>
> The definition of 'parameter' doesn't seem to allow whitespace:
>
> content := "Content-Type" ":" type "/" subtype *(";" parameter)
> parameter := attribute "=" value
> attribute := token ; case-insensitive
> value := token / quoted-string
> token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
Hmmm. Well, that's probably an error in the RFC. Note that in the RFC
itself they are providing a few examples that exactly match cmpilato's
example. I couldn't find anything in the RFC indicating that
"plain/text ;charset=UTF-8" is valid.
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: [PATCH] validate MIME type correctly
Posted by Daniel Shahaf <d....@daniel.shahaf.co.il>.
Stefan Sperling wrote on Mon, 28 Apr 2008 at 17:00 +0200:
> On Mon, Apr 28, 2008 at 10:31:58AM -0400, C. Michael Pilato wrote:
> > $ svn pget svn:mime-type ~/projects/subversion/COMMITTERS
> > text/plain; charset=UTF-8
>
> Btw, if there's any space before the semicolon (i.e. 'text/plain ;')
> trunk will now raise an error. RFC 1521 seems to agree with this:
>
> content := "Content-Type" ":" type "/" subtype *(";" parameter)
> subtype := token
> token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
>
> But I hope we're not breaking anyone's setup.
>
>
Why is a space allowed *after* the semicolon (as in cmpilato's example)?
The definition of 'parameter' doesn't seem to allow whitespace:
content := "Content-Type" ":" type "/" subtype *(";" parameter)
parameter := attribute "=" value
attribute := token ; case-insensitive
value := token / quoted-string
token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] validate MIME type correctly
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Apr 28, 2008 at 10:31:58AM -0400, C. Michael Pilato wrote:
> Stefan Sperling wrote:
>>> except I am not sure if you want to
>>> allow svn:mime_type="type/subtype ; parameter = value"
>>
>> The code explicitly allows this. I don't know whether this
>> is good/bad, but I don't think we should break this since
>> it's probably being used in the wild somewhere.
>
> Indeed.
>
> $ svn pget svn:mime-type ~/projects/subversion/COMMITTERS
> text/plain; charset=UTF-8
Heh :)
Btw, if there's any space before the semicolon (i.e. 'text/plain ;')
trunk will now raise an error. RFC 1521 seems to agree with this:
content := "Content-Type" ":" type "/" subtype *(";" parameter)
subtype := token
token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
But I hope we're not breaking anyone's setup.
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: [PATCH] validate MIME type correctly
Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Sperling wrote:
>> except I am not sure if you want to
>> allow svn:mime_type="type/subtype ; parameter = value"
>
> The code explicitly allows this. I don't know whether this
> is good/bad, but I don't think we should break this since
> it's probably being used in the wild somewhere.
Indeed.
$ svn pget svn:mime-type ~/projects/subversion/COMMITTERS
text/plain; charset=UTF-8
$
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [PATCH] validate MIME type correctly (was: Re: svn: MIME type
'text/x-c++' ends with non-alphanumeric) character
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Apr 26, 2008 at 01:34:22PM +0200, Alan Barrett wrote:
> On Sat, 26 Apr 2008, Stefan Sperling wrote:
> > Here it is. Now hopefully correctly checking the whole mime type
> > for illegal characters. This should conform to RFC 1521 if I
> > unterstood the RFC correctly.
>
> That looks fine to me,
Thanks.
> except I am not sure if you want to
> allow svn:mime_type="type/subtype ; parameter = value"
The code explicitly allows this. I don't know whether this
is good/bad, but I don't think we should break this since
it's probably being used in the wild somewhere.
Here's the whole (patched) function again for reference,
note the comment at the top:
svn_error_t *
svn_mime_type_validate(const char *mime_type, apr_pool_t *pool)
{
/* Since svn:mime-type can actually contain a full content type
specification, e.g., "text/html; charset=UTF-8", make sure we're
only looking at the media type here. */
const apr_size_t len = strcspn(mime_type, "; ");
const char *const slash_pos = strchr(mime_type, '/');
int i;
const char *tspecials = "()<>@,;:\\\"/[]?=";
if (len == 0)
return svn_error_createf
(SVN_ERR_BAD_MIME_TYPE, NULL,
_("MIME type '%s' has empty media type"), mime_type);
if (slash_pos == NULL || slash_pos >= &mime_type[len])
return svn_error_createf
(SVN_ERR_BAD_MIME_TYPE, NULL,
_("MIME type '%s' does not contain '/'"), mime_type);
/* Check the mime type for illegal characters. See RFC 1521. */
for (i = 0; i < len; i++)
{
if (&mime_type[i] != slash_pos
&& (! apr_isascii(mime_type[i])
|| apr_iscntrl(mime_type[i])
|| apr_isspace(mime_type[i])
|| (strchr(tspecials, mime_type[i]) != NULL)))
return svn_error_createf
(SVN_ERR_BAD_MIME_TYPE, NULL,
_("MIME type '%s' contains invalid character '%c'"),
mime_type, mime_type[i]);
}
return SVN_NO_ERROR;
}
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: [PATCH] validate MIME type correctly (was: Re: svn: MIME type
'text/x-c++' ends with non-alphanumeric) character
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 26 Apr 2008, Stefan Sperling wrote:
> Here it is. Now hopefully correctly checking the whole mime type
> for illegal characters. This should conform to RFC 1521 if I
> unterstood the RFC correctly.
That looks fine to me, except I am not sure if you want to
allow svn:mime_type="type/subtype ; parameter = value"
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] validate MIME type correctly (was: Re: svn: MIME type
'text/x-c++' ends with non-alphanumeric) character
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Apr 26, 2008 at 01:14:11PM +0200, Stefan Sperling wrote:
> On Sat, Apr 26, 2008 at 12:58:30PM +0200, Stefan Sperling wrote:
> >
> > Thread moved to dev@
>
> > Would this be better?
> >
> > Can anyone test if this breaks anything?
> > (There seem to be no mime-type-related unit tests...)
> >
> > Index: subversion/libsvn_subr/validate.c
> > ===================================================================
> > --- subversion/libsvn_subr/validate.c (revision 30791)
> > +++ subversion/libsvn_subr/validate.c (working copy)
> > @@ -41,6 +41,8 @@ svn_mime_type_validate(const char *mime_type, apr_
> > only looking at the media type here. */
> > const apr_size_t len = strcspn(mime_type, "; ");
> > const char *const slash_pos = strchr(mime_type, '/');
> > + int i;
> > + const char *tspecials = "()<>@,;:\\\"/[]?="; /* see RFC 1521 */
>
> Hrmm, with that slash tspecials, looping over the whole mime-type
> and just not the subtype will break the whole function pretty much :/
>
> I'll send a better patch in a minute.
Here it is. Now hopefully correctly checking the whole mime type
for illegal characters. This should conform to RFC 1521 if I
unterstood the RFC correctly.
Index: subversion/libsvn_subr/validate.c
===================================================================
--- subversion/libsvn_subr/validate.c (revision 30791)
+++ subversion/libsvn_subr/validate.c (working copy)
@@ -41,6 +41,8 @@ svn_mime_type_validate(const char *mime_type, apr_
only looking at the media type here. */
const apr_size_t len = strcspn(mime_type, "; ");
const char *const slash_pos = strchr(mime_type, '/');
+ int i;
+ const char *tspecials = "()<>@,;:\\\"/[]?=";
if (len == 0)
return svn_error_createf
@@ -52,10 +54,19 @@ svn_mime_type_validate(const char *mime_type, apr_
(SVN_ERR_BAD_MIME_TYPE, NULL,
_("MIME type '%s' does not contain '/'"), mime_type);
- if (! apr_isalnum(mime_type[len - 1]))
- return svn_error_createf
- (SVN_ERR_BAD_MIME_TYPE, NULL,
- _("MIME type '%s' ends with non-alphanumeric character"), mime_type);
+ /* Check the mime type for illegal characters. See RFC 1521. */
+ for (i = 0; i < len; i++)
+ {
+ if (&mime_type[i] != slash_pos
+ && (! apr_isascii(mime_type[i])
+ || apr_iscntrl(mime_type[i])
+ || apr_isspace(mime_type[i])
+ || (strchr(tspecials, mime_type[i]) != NULL)))
+ return svn_error_createf
+ (SVN_ERR_BAD_MIME_TYPE, NULL,
+ _("MIME type '%s' contains invalid character '%c'"),
+ mime_type, mime_type[i]);
+ }
return SVN_NO_ERROR;
}
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: svn: MIME type 'text/x-c++' ends with non-alphanumeric
character
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Apr 26, 2008 at 12:58:30PM +0200, Stefan Sperling wrote:
>
> Thread moved to dev@
> Would this be better?
>
> Can anyone test if this breaks anything?
> (There seem to be no mime-type-related unit tests...)
>
> Index: subversion/libsvn_subr/validate.c
> ===================================================================
> --- subversion/libsvn_subr/validate.c (revision 30791)
> +++ subversion/libsvn_subr/validate.c (working copy)
> @@ -41,6 +41,8 @@ svn_mime_type_validate(const char *mime_type, apr_
> only looking at the media type here. */
> const apr_size_t len = strcspn(mime_type, "; ");
> const char *const slash_pos = strchr(mime_type, '/');
> + int i;
> + const char *tspecials = "()<>@,;:\\\"/[]?="; /* see RFC 1521 */
Hrmm, with that slash tspecials, looping over the whole mime-type
and just not the subtype will break the whole function pretty much :/
I'll send a better patch in a minute.
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No