On Tue, 2010-02-23 at 14:15 +0200, Mircea Carasel wrote:
> 
> Another question: The Raymond's patch uses replication mechanism to
> push certificates to secondary hosts. I really like this idea, but
> this opens
> a new question that I would like to clarify.
> 
> In sipXconfig,  the file replication mechanism transforms the file
> content into a base 64 encoded String, and pushes this content to a
> location.
> 
> >From ReplicationManagerImpl:
> 
>                 byte[] payloadBytes = outStream.toByteArray();
>                 String content = encodeBase64(payloadBytes);
> 
>                 FileApi api =
> m_fileApiProvider.getApi(locations[i].getProcessMonitorUrl());
>                 success = api.replace(getHostname(), file.getPath(),
> PERMISSIONS, content);
> This would work fine for PEM certificates I suppose.
> I don't know if we already have support for DER certificates import,
> but I suppose that at least we will have in the future, and I think
> that it is
> not OK to take DER encoded content and make  a String of it during
> replication.
> 
> What do you think? Is there any replication support available for
> binary files, or we should go ahead and use current replication
> mechanism ?

The current mechanism is binary-safe - the base64 transformation is
reversed at the other end.

I plan to replace that mechanism with the use of HTTP PUT, which is
inherently binary-safe, and does not require the overhead in performance
or size of doing the base64 encode/decode.  That's not going to make 4.2
though, since it would touch too many places in sipXconfig.

I also don't think we'll try to get DER encoded certificates into 4.2


_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to