[PUBLISHING-45] Weblogic does not accept CRLF characters set in header Created: 27/Mar/18  Updated: 29/Mar/22  Resolved: 11/Apr/18

Status: Closed
Project: Publishing
Component/s: None
Affects Version/s: 1.0.2
Fix Version/s: 1.0.4

Type: Bug Priority: Major
Reporter: Dai Ha Assignee: Dai Ha
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 1d 3.5h
Original Estimate: 0d

Issue Links:
Relates
relates to PUBLISHING-37 CRLF validation problem with Spring S... Closed
dependency
depends upon MGNLWLS-17 Weblogic module is no longer compatib... Closed
relation
is related to PUBLISHING-48 Move headersDispatcher.error i18n key... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Saigon 140, Saigon 141, Saigon 142
Story Points: 3
Team: Nucleus

 Description   

This error occurs during weblogic 5.6 startup after change from activation to publishing module:

<Mar 22, 2018 4:13:25,764 PM ICT> <Error> <HTTP> <BEA-101020> <[ServletContext@656342546[app:magnoliaPublic module:magnoliaPublic.war path:null spec-version:3.1]] Servlet failed with an Exception
java.lang.IllegalArgumentException: Header:sa_attribute_message Cannot contain CRLF Charcters
        at weblogic.servlet.internal.ServletResponseImpl.checkForCRLFChars(ServletResponseImpl.java:1919)
        at weblogic.servlet.internal.ServletResponseImpl.setHeader(ServletResponseImpl.java:1087)
        at javax.servlet.http.HttpServletResponseWrapper.setHeader(HttpServletResponseWrapper.java:203)
        at info.magnolia.publishing.receiver.dispatcher.HeadersDispatcher.setResponseHeaders(HeadersDispatcher.java:155)
        at info.magnolia.publishing.receiver.dispatcher.HeadersDispatcher.onOperationExecutionDone(HeadersDispatcher.java:105)
        Truncated. see log file for complete stacktrace
> 
2018-03-22 16:13:25,797 ERROR nfo.magnolia.publishing.command.PublicationCommand: Receiver: magnoliaPublic7001, error: Unable to contact receiver, HTTP response code: 500.
info.magnolia.publishing.exception.PublicationException: Unable to contact receiver, HTTP response code: 500.
        at info.magnolia.publishing.sender.operation.HttpPublicationOperation.execute(HttpPublicationOperation.java:163) ~[magnolia-publishing-sender-1.0.2-SNAPSHOT.jar:?]
        at info.magnolia.publishing.sender.operation.HttpPublicationOperation.execute(HttpPublicationOperation.java:74) ~[magnolia-publishing-sender-1.0.2-SNAPSHOT.jar:?]
        at info.magnolia.publishing.transactional.sender.TransactionalSender$2.doRun(TransactionalSender.java:110) ~[magnolia-publishing-transactional-sender-1.0.jar:?]
        at info.magnolia.publishing.sender.AbstractSender$Task.run(AbstractSender.java:291) ~[magnolia-publishing-core-1.0.2-SNAPSHOT.jar:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_162]
        at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:111) ~[guava-20.0.jar:?]
        at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:58) ~[guava-20.0.jar:?]
        at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:75) ~[guava-20.0.jar:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_162]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_162]
        at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_162]
2018-03-22 16:13:25,806 ERROR info.magnolia.module.scheduler.CommandJob         : Cannot execute command {0}-{1}.
info.magnolia.publishing.exception.PublicationException: <ul><li>magnoliaPublic7001: Unable to contact receiver, HTTP response code: 500.</li></ul>
        at info.magnolia.publishing.command.PublicationCommand.execute(PublicationCommand.java:162) ~[magnolia-publishing-core-1.0.2-SNAPSHOT.jar:?]
        at info.magnolia.personalization.command.PersonalizationPublicationCommand.execute(PersonalizationPublicationCommand.java:46) ~[magnolia-personalization-integration-1.5.2.jar:?]
        at info.magnolia.commands.MgnlCommand.executeSynchronized(MgnlCommand.java:80) ~[magnolia-core-5.6.3-SNAPSHOT.jar:?]
        at info.magnolia.commands.MgnlCommand.execute(MgnlCommand.java:69) ~[magnolia-core-5.6.3-SNAPSHOT.jar:?]
        at info.magnolia.module.scheduler.CommandJob.execute(CommandJob.java:110) [magnolia-module-scheduler-2.3.1.jar:?]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) [quartz-2.2.3.jar:?]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [quartz-2.2.3.jar:?]
2018-03-22 16:13:25,845 INFO  orkflow.jbpm.workitem.handler.AsyncWorkItemHandler: WorkItem [asyncCommand] was aborted.

Apparently, i18n add some CRLF characters to the content with this call

response.setHeader(ACTIVATION_ATTRIBUTE_MESSAGE, i18n.translate("publishing-receiver.headersDispatcher.error", getWebapp(), message));


 Comments   
Comment by Hieu Nguyen Duc [ 16/Apr/18 ]

Verified on bundle magnolia-enterprise-weblogic-webapp-5.6.6-20180413.101856-6, WebLogic 12.2.1.3 and Java 1.8.0_112.

+ Publishing works fine

+ Content Delivery requests work fine.

Comment by Mikaël Geljić [ 03/May/18 ]

efochr, receiver doesn't translate nor displays any user message.
Even then, it wouldn't know what language was the author using on the sender.

So yes moving the messaging/translation to the sender made sense. But did we forget to move the i18n key as well?

Comment by Evzen Fochr [ 03/May/18 ]

mgeljic I see the point in language we need to translate to. But than do we need to send i18n key at all? Isn't getWebapp(), message enough ? And yes we should move i18n key to sender and change it to publishing-sender.headersDispatcher.error ?

Comment by Mikaël Geljić [ 03/May/18 ]

Yes now it's rather used as an "error-code" than an i18n key; we could still compute the key from a (shorter) error code. Feel free to file a follow-up.

Generated at Mon Feb 12 10:34:52 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.