[ 
https://issues.apache.org/jira/browse/SHINDIG-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marshall Shi updated SHINDIG-1890:
----------------------------------

    Description: 
The gadgets js servlet response can never be 304. Even if the If-Modified-Since 
header present in the request header and the gadgets js content has been cached 
in browser.

Shindig provides required js processors and optional js processors. In current 
implementation, the IfModifiedSinceProcessor is doing the right thing to set a 
304 response status code and stop the other optional js processors. But 
CompilationProcessor, which is a required js processor, will always run and 
always use a 200 to overwrite the 304 status code. Thus in the gadget js 
servlet layer, it won't return 304.

The proposed fix is to move IfModifiedSinceProcessor to a third type of 
processor: preprocessors. If one of the preprocessors return false, the entire 
process will be returned. So the closure compilor won't start. In the gadget js 
servlet, also add a check for 304 status code.

  was:
The gadgets js servlet response can never be 304. Even if the If-Modified-Since 
header present in the request header and the gadgets js content has been cached 
in browser.

Shindig provides required js processors and optional js processors. In current 
implementation, the IfModifiedSinceProcessor is doing the right thing to set a 
304 response status code and stop the other optional js processors. But 
CompilationProcessor, which is a required js processor, will always run and 
always use a 200 to overwrite the 304 status code. Thus in the gadget js 
servlet layer, it won't return 304.

The proposed fix is to add a check in the beginning of CompilationProcessor, if 
the status code is already set to 304, the closure compilor won't start. In the 
gadget js servlet, also add a check for 304 status code. 

    
> If-Modified-Since header not handled properly in gadgets js servlet
> -------------------------------------------------------------------
>
>                 Key: SHINDIG-1890
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1890
>             Project: Shindig
>          Issue Type: Bug
>          Components: Java
>    Affects Versions: 2.5.0-beta5
>            Reporter: Marshall Shi
>             Fix For: 2.5.0-beta5
>
>
> The gadgets js servlet response can never be 304. Even if the 
> If-Modified-Since header present in the request header and the gadgets js 
> content has been cached in browser.
> Shindig provides required js processors and optional js processors. In 
> current implementation, the IfModifiedSinceProcessor is doing the right thing 
> to set a 304 response status code and stop the other optional js processors. 
> But CompilationProcessor, which is a required js processor, will always run 
> and always use a 200 to overwrite the 304 status code. Thus in the gadget js 
> servlet layer, it won't return 304.
> The proposed fix is to move IfModifiedSinceProcessor to a third type of 
> processor: preprocessors. If one of the preprocessors return false, the 
> entire process will be returned. So the closure compilor won't start. In the 
> gadget js servlet, also add a check for 304 status code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to