[richfaces-issues] [JBoss JIRA] Commented: (RF-7304) RIchfaces controls don't work over HTTPS on the first request

[Dave Oxley (JIRA)]

    [ https://jira.jboss.org/jira/browse/RF-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12484057#action_12484057 ] 

Dave Oxley commented on RF-7304:
--------------------------------

Just wanted to say that we still have this issue. I haven't had time to try on JBoss or produce a simple test case yet. But I would say that I think to reproduce you will need to configure pages.xml so only some pages are https rather than all. i.e. Instead of 
<page view-id="/*" scheme="https">
I have this:
<page view-id="*" scheme="http" />
<page view-id="/login.xhtml" scheme="https"/>

> RIchfaces controls don't work over HTTPS on the first request
> -------------------------------------------------------------
>
>                 Key: RF-7304
>                 URL: https://jira.jboss.org/jira/browse/RF-7304
>             Project: RichFaces
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.3.1
>         Environment: Gentoo Linux, Apache 2.2.10, Tomcat 6.0.18, Seam 2.1.2CR2, Richfaces 3.3.1GA
>            Reporter: Dave Oxley
>            Assignee: Tsikhon Kuprevich
>             Fix For: 3.3.2.CR1
>
>
> We are developing an web application using Seam and Richfaces. We have changed some pages to use HTTPS by setting scheme="https" against the relevant pages in pages.xml. Unfortunately we noticed that for first request to each type of Richfaces control the control did not render properly, but subsequent requests rendered correctly. We tried clearing the browser cache but this did not recreate the issue. Only restarting the application recreated the issue. We then looked at the Apache access logs to see what was happening and found that the first request to the xcss file resulted in a redirect back to HTTP for the incorrect path. The easiest way to describe it is to show the access logs:
> First request:
> ssl_access_log:
> 127.0.0.1 - - [03/Jun/2009:13:34:58 +1000] "GET /a4j/s/3_3_1.GAcss/picklist.xcss/DATB/eAELXT5DOhSIAQ!sA18_ HTTP/1.1" 302 -
> access_log:
> 127.0.0.1 - - [03/Jun/2009:13:34:59 +1000] "GET /css/picklist.xcss?cid=1 HTTP/1.1" 404 15327
> Subsequent requests:
> ssl_access_log:
> 127.0.0.1 - - [03/Jun/2009:13:35:32 +1000] "GET /a4j/s/3_3_1.GAcss/picklist.xcss/DATB/eAELXT5DOhSIAQ!sA18_ HTTP/1.1" 200 4912
> No entry in access_log.
> After we found this in the logs we found we could recreate the issue by just issuing the problem URL after a server restart:
> https://127.0.0.1//a4j/s/3_3_1.GAcss/picklist.xcss/DATB/eAELXT5DOhSIAQ!sA18_
> which redirects to http for the first request and works for all subsequent requests.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira