Expand my Community achievements bar.

SOLVED

Replication Agent: Additional HTTP header breaks replication

Avatar

Level 1

When configuring an additional HTTP header for a replication agent the replication breaks due to the necessary standard headers not being sent anymore.

Replication test without additional headers (see the three headers):

Create new HttpClient for Default Agent

* Auth User: replication-receiver

* HTTP Version: 1.1

adding header: Action:Test

adding header: Path:/content

adding header: Handle:/content

deserialize content for delivery

No message body: Content ReplicationContent.VOID is empty

Sending POST request to https://dev-aem-publish.xxx/bin/receive?sling:authRequestLogin=1

sent. Response: 200 OK

Replication test with additional header set (default headers are gone):

Create new HttpClient for Default Agent

* Auth User: replication-receiver

* HTTP Version: 1.1

adding header: Host:dev-aem-publish1.aws

deserialize content for delivery

No message body: Content ReplicationContent.VOID is empty

Sending POST request to https://dev-aem-publish.xxx/bin/receive?sling:authRequestLogin=1

sent. Response: 400 Bad Request

Since the header values for "path" and "handle" are dynamic I cannot just set them in the configuration... So is this a feature I misunderstood or a bug?

I experienced this issue on a fresh AEM 6.3.3.1 instance but could reproduce it even on 6.3.2.1.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

I guess that as soon as you start to add custom headers, the default headers are gone ...

Just add these headers as well:

Action = {action}

Path = {path}

Handle = {path}

these 2 values in curly brackets will be replaced properly by the replication internally.

View solution in original post

2 Replies

Avatar

Correct answer by
Employee Advisor

I guess that as soon as you start to add custom headers, the default headers are gone ...

Just add these headers as well:

Action = {action}

Path = {path}

Handle = {path}

these 2 values in curly brackets will be replaced properly by the replication internally.

Avatar

Level 1

Thanks Jörg, that did the trick.

Nevertheless I reported it as a bug since the configuration dialog says "additional HTTP headers" - so it implies that the default headers are not getting replaced.