shailendra333 / webutilities

Automatically exported from code.google.com/p/webutilities
0 stars 0 forks source link

Incorrect chaining order results in wrong setCharacterEncoding on ResponseCacheFilter #26

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.call a .js on tomcat with windows
2.the first time comes with utf-8
3.next time comes with ISO

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
v0.0.5 (rev 245)

Please provide any additional information below.

on ResponseCacheFilter i saw you've commented (commit 237)

//fillResponseFromCache(httpServletResponse, cacheObject.getModuleResponse());

and putted this instead 
cacheObject.getWebUtilitiesResponseWrapper().fill(httpServletResponse);
this method doesn't preserve the previous charsetEnconding, so when cached 
resources return system charset, and not UTF-8

Original issue reported on code.google.com by marianoy...@gmail.com on 10 Nov 2011 at 2:44

GoogleCodeExporter commented 9 years ago
I've solved it!

Indeed it wasn't what i supposed.

com.googlecode.webutilities.filters.CharacterEncodingFilter was after 
com.googlecode.webutilities.filters.ResponseCacheFilter as you recomend on 
http://code.google.com/p/webutilities/wiki/ChainingOrder

so whene a resource was cached, no UTF-8 enconding was set

now i've putted CharacterEncodingFilter  before ResponseCacheFilter  and it's 
working. Maybe it's better if you change the order in that webpage

Thank you!

Original comment by marianoy...@gmail.com on 10 Nov 2011 at 2:57

GoogleCodeExporter commented 9 years ago
Thanks for report and quick followup update. Sure, I will update the wiki to 
reflect correct order.

Original comment by rr.patil...@gmail.com on 10 Nov 2011 at 4:10

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by rr.patil...@gmail.com on 10 Nov 2011 at 4:11

GoogleCodeExporter commented 9 years ago
At the end i still have the problem. I dont know when, but after using my 
webpage for a while it start returning ISO.

To avoid the problem i had to use ?_skipcache_=1 on my .js files

So i don't know where the problem is.

Original comment by marianoy...@gmail.com on 10 Nov 2011 at 4:49

GoogleCodeExporter commented 9 years ago
If you find more details and exact steps to repro this, do share. That will be 
helpful to find the cause and fix it.

Original comment by rr.patil...@gmail.com on 11 Nov 2011 at 4:36

GoogleCodeExporter commented 9 years ago
Need to investigate more , repro it and find the root cause.

Original comment by rr.patil...@gmail.com on 8 Dec 2011 at 6:13

GoogleCodeExporter commented 9 years ago

Original comment by rr.patil...@gmail.com on 8 Dec 2011 at 6:17

GoogleCodeExporter commented 9 years ago
This problem is always reproducible while forcing the browser to clear cache 
using CTRL + F5.
1) Initially, request passes thru CharacterEncodingFilter and so the encoding 
set to "UTF-8"
2) Later, incase of forcing the browser to clear cache, both the 
"If-Modified-Since" or "If-None-Match" header will be null and so the response 
is being filled from cache. This time CharacterEncodingFilter will be skipped 
as its not "doChain"-ed further. (considering the order suggested by you in the 
wiki).
3) While filling response from cache thru WebUtilitiesResponseWrapper.fill() 
using the statement 
"response.setCharacterEncoding(this.getCharacterEncoding())", 
"this.getCharacterEncoding()" always returns default encoding "ISO-8859-1".

Problem may be the encoding "UTF-8" is not preserved in cache response wrapper 
while creating the cache.

Original comment by chandran...@gmail.com on 24 Jan 2012 at 4:41

GoogleCodeExporter commented 9 years ago
In RAD + Websphere environment for the above scenario (forcing the browser to 
clear cache using CTRL + F5), while filling response from cache thru 
WebUtilitiesResponseWrapper.fill() using the statement 
"response.setCharacterEncoding(this.getCharacterEncoding())", 
"this.getCharacterEncoding()" always throws NullPointerException. So the filter 
execution interupted and getting the server error response. 

The same statement "response.setCharacterEncoding(this.getCharacterEncoding())" 
is working fine in (Eclipse + Tomcat) environment but returns default encoding 
"ISO-8859-1".

Original comment by chandran...@gmail.com on 24 Jan 2012 at 4:51

GoogleCodeExporter commented 9 years ago

Original comment by rr.patil...@gmail.com on 28 Jan 2012 at 4:22

GoogleCodeExporter commented 9 years ago
https://github.com/rpatil26/webutilities/commit/4876b6a17f87e58c36e6b5d9764c16dc
24005092

Original comment by rr.patil...@gmail.com on 25 Feb 2013 at 6:12