[WICKET-3639] if and when a xml prolog is written to the response

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.5-RC5
• Assignee: Juegen Donnerstag
• Reporter: Juegen Donnerstag
• Created: 24/Apr/11 08:01
• Updated: 10/Jun/11 19:51
• Resolved: 10/Jun/11 19:51

Description

Copied from mail thread: http://apache-wicket.1842946.n4.nabble.com/Re-Missing-XML-declaration-in-error-page-td3466395.html

I had another look at Page.configureResponse(). I agree that the
current behavior is a bit strange.

If the page markup contains the xml prolog, than a xml prolog is
written to the response, with the encoding provided by
application.getRequestCycleSettings().getResponseRequestEncoding().
If page markup contain no xml prolog, than no xml prolog is written
into the response.

I think we should remove get/setStripXmlDeclarationFromOutput() and
replace it with is/setInsertXmlProlog. An no matter whether the page
markup contains a prolog or not, only if the application setting is
true, a prolog is written or not. If RCS encoding is null, the prolog
will still be written, but without encoding attribute.

• it more clearly separates markup reading from response writing
• allow to enable/disable xml prolog for all pages of the application,
  irrespective whether the markup has the prolog
• the response prolog can no longer be controlled via the page markup.
  E.g. all pages with style or variation "IE" containing IE specific
  markup, have slightly different markup (don't know if anybody is using
  it like that). We could still allow that by introducing
  WebApplication.isInsertXmlProlog with Page parameter, which can be
  overriden by user on demand. By default it return
  markupSettings.isInsert...

Any thoughts?

-Juergen

• Hide quoted text -

On Fri, Apr 22, 2011 at 11:12 AM, Martin Grigorov <[e-mail]> wrote:
> Hi Juergen,
>
> Thanks for the explanation. It is more clear now.
> I meant using IResponseFilter to add the XML prolog if the user
> application really wants to.
> Now Page#configureResponse() sets it only for the pages which have it
> in their markup. If a MyPage.html don't have it and all panels used in
> that page use non-ascii characters and have the prolog then it is not
> set in the produced final page markup.
>
> I'm not saying we need to change it. If I want the prolog then I'd use
> my own IResponseFilter to add it to all pages - mine and re-used from
> libraries (like Wicket internals).
>
> The problem reported by Petr is fixed in 1.5. All pages have the prolog.
>
> On Fri, Apr 22, 2011 at 10:10 AM, Juergen Donnerstag
> <[e-mail]> wrote:
>> the setting/exception is to make sure that all markup files have
>> proper encoding. Think about moving markup files from your local latop
>> onto a production server. Who guarantees that in your markup are only
>> ascii chars? Who guarantees the prod server has the same default
>> encoding than your devs laptops (and your dev might be working
>> somewhere on the globe). And though the response needs to be browser
>> aware, because especially historically every browser version behaved
>> different depending on the presence of the xml prolog in response, it
>> doesn't (and shouldn't) matter for Wicket's markup. Use whatever web
>> editor you want, with whatever encoding you want, just make sure the
>> xml prolog is present.
>>
>> Wicket always removes the xml prolog from the markup upon reading,
>> only the encoding (of Pages) get remembered and used as default for
>> configuring the Page response. It is Page.configureResponse which
>> writes a new xml prolog to the response. You can omit that by simply
>> setting getMarkupSettings().setStripXmlDeclarationFromOutput(false).
>> No need for response filter or whatever.
>>
>> IMO every Wicket markup, especially of what we deliver, should have
>> the xml prolog.
>>
>> -Juergen
>>
>> On Thu, Apr 21, 2011 at 9:04 PM, Martin Grigorov <[e-mail]> wrote:
>>> I don't know the history of this recommendation. The log message says
>>> "The markup file does not have a XML declaration prolog: " +
>>> markupResourceData.getResource() + ". It is more save to use it."
>>>
>>> I'm not sure how it is more safe this way (if we keep this message we
>>> need to fix the typo at least )
>>> I'd vote to remove this prolog all together. If the user app needs it
>>> then it is quite easy to use IResponseFilter to add it for each and
>>> every page.
>>>
>>>
>>> On Thu, Apr 21, 2011 at 7:51 PM, Pedro Santos <[e-mail]> wrote:
>>>>
>>>> He Petr, by add the prolog in the html files those pages are not correctly
>>>> rendered in IE8, IMO opinion the best option we have now is to move the
>>>> Apache header in those files to inside the html tag plus restore the prolog
>>>> [1].
>>>>
>>>> Devs, I don't know if we can freely move the Apache header to outside the
>>>> top of our files. Also reading the header politic site [2], I don't get if
>>>> we can simple remove it. Does the exception page fits the "without any
>>>> degree of creativity" requirement since it has no programming code? It is
>>>> just static markup...
>>>>
>>>> 1 - https://issues.apache.org/jira/browse/WICKET-3566
>>>> 2 - http://www.apache.org/legal/src-headers.html
>>>>
>>>> <https://issues.apache.org/jira/browse/WICKET-3566>
>>>> On Thu, Apr 21, 2011 at 2:26 AM, Petr Gladkikh <[e-mail]> wrote:
>>>>
>>>> > I am trying to upgrage from wicket 1.4.1 to 1.4.17 and have following
>>>> > problem.
>>>> > In our application we configure
>>>> > getMarkupSettings().setThrowExceptionOnMissingXmlDeclaration(true);
>>>> >
>>>> > This prevents all Wicket's default pages from rendering since none of
>>>> > them contain XML prolog anymore. E.g. none of HTML files in
>>>> >
>>>> > apache-wicket-1.4.17/src/wicket/src/main/java/org/apache/wicket/markup/html/pages
>>>> > contain XML declaration prolog. When wicket tries to show error page
>>>> > exception is thrown. Top of stack trace is:
>>>> > at org.apache.wicket.markup.MarkupParser.parse(MarkupParser.java:280)
>>>> > at
>>>> > org.apache.wicket.markup.loader.SimpleMarkupLoader.loadMarkup(SimpleMarkupLoader.java:52)
>>>> > at
>>>> > org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.loadMarkup(InheritedMarkupMarkupLoader.java:62)
>>>> > at
>>>> > org.apache.wicket.markup.loader.DefaultMarkupLoader.loadMarkup(DefaultMarkupLoader.java:55)
>>>> > at org.apache.wicket.markup.MarkupCache.loadMarkup(MarkupCache.java:465)
>>>> > at
>>>> > org.apache.wicket.markup.MarkupCache.loadMarkupAndWatchForChanges(MarkupCache.java:561)
>>>> > at org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:325)
>>>> > at
>>>> > org.apache.wicket.markup.MarkupCache.getMarkupStream(MarkupCache.java:216)
>>>> > at
>>>> > org.apache.wicket.MarkupContainer.getAssociatedMarkupStream(MarkupContainer.java:351)
>>>> > at org.apache.wicket.Page.onRender(Page.java:1587)
>>>> > at org.apache.wicket.Component.render(Component.java:2521)
>>>> > at org.apache.wicket.Page.renderPage(Page.java:932)
>>>> >
>>>> > I can work around by switching these exceptions off. But I think that
>>>> > the problem should be fixed otherwise since even when these exceptions
>>>> > are switched off following message is written to log:
>>>> > log.debug("The markup file does not have a XML declaration prolog: " +
>>>> > markupResourceData.getResource() + ". It is more save to use it. E.g.
>>>> > <?xml version=\"1.0\" encoding=\"UTF-8\" ?>");
>>>> >
>>>> > –
>>>> > Petr Gladkikh
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: [e-mail]
>>>> > For additional commands, e-mail: [e-mail]
>>>> >
>>>> >
>>>>
>>>>
>>>> –
>>>> Pedro Henrique Oliveira dos Santos
>>>
>>>
>>>
>>> –
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>
>
>
>
> –
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>