You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Joose Vettenranta <jo...@iki.fi> on 2007/01/12 10:43:09 UTC
problem with headers
Hello,
I have like this in sitemap:
<map:match pattern="internal/action/upload">
<map:read type="resource" src="{flow-attribute:path}/{flow-
attribute:file}" mime-type="{flow-attribute:mimetype}" />
</map:match>
It works for some but not for every file I have.
For the ones it does not work, result is like this: http://
joose.iki.fi/error.jpeg
Using cocoon 2.1.7, jetty, apache as proxy in front of cocoon and
java j2sdk1.4.2_10
Anyideas how to fix this or what the problem might be?
- Joose
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: problem with headers
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 15, 2007, at 4:39 AM, Joose Vettenranta wrote:
> [...] So it might indicate problem with caching and mime-types.
hmmm....
https://issues.apache.org/jira/browse/COCOON-1624
???
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: problem with headers
Posted by Joose Vettenranta <jo...@iki.fi>.
Mark Lundquist kirjoitti 13.1.2007 kello 23.31:
>> I have like this in sitemap:
>>
>> <map:match pattern="internal/action/upload">
>> <map:read type="resource" src="{flow-attribute:path}/{flow-
>> attribute:file}" mime-type="{flow-attribute:mimetype}" />
>> </map:match>
>>
>> It works for some but not for every file I have.
>>
>> For the ones it does not work, result is like this: http://
>> joose.iki.fi/error.jpeg
>
> That's really weird. Some thoughts:
> 1) You say you think it has to do with mime type. Why?
Because matcher with static mime-type works ok, but when I change
mime-type per request -> no luck.
>
> 2) There's nothing in ResourceReader.java that explains why you
> would get this bogus Content-Length header inserted into the
> payload of the HTTP response;
Well, I said this is odd =)
> 3) If this were broken, lots of people would have this problem,
> because ResourceReader is used all the time to serve plain old
> static content;
It works when I don't dynamicly change mime-type with every request.
> 5) You say your pipeline works "for some images and not for
> others" (or something along those lines). I'll bet the same ones
> are always broken, right?
Yep
> I'll bet you have some image files that are just crapped up from
> the start, I mean just the plain files right there on the disk!
> I'll bet they are corrupted, and the reader is working just fine.
Hmm.. Nope. I have for images like this on filesystem:
<id> = original image
<id>.thumb = thumbnail
<id>.biggerthumb = thumbnail
<id>.info = information about image
for thumbnails I have static mime-type: image/jpeg - works ok
for original images I have dynamic mime-type..
thumbnails always works. Also original files are correct and not
corrupted. I have also tried to copy thumbnail to original image ==
no work. What makes me think it's about mime-types is that when
Firefox tries to show image/something it always says image is type
"image/jpeg".
I made now it so that it (matcher) is in noncaching pipeline and it
seems to work when I set content-disposition header with action. So
it might indicate problem with caching and mime-types.
- Joose
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: problem with headers
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 12, 2007, at 1:43 AM, Joose Vettenranta wrote:
> Hello,
>
> I have like this in sitemap:
>
> <map:match pattern="internal/action/upload">
> <map:read type="resource"
> src="{flow-attribute:path}/{flow-attribute:file}"
> mime-type="{flow-attribute:mimetype}" />
> </map:match>
>
> It works for some but not for every file I have.
>
> For the ones it does not work, result is like this:
> http://joose.iki.fi/error.jpeg
That's really weird. Some thoughts:
1) You say you think it has to do with mime type. Why?
2) There's nothing in ResourceReader.java that explains why you would
get this bogus Content-Length header inserted into the payload of the
HTTP response;
3) If this were broken, lots of people would have this problem, because
ResourceReader is used all the time to serve plain old static content;
4) The Content-Length value in the header is greater than the value of
the bogus Content-Length header line in the content, by exactly the
number of characters in that bogus line;
5) You say your pipeline works "for some images and not for others" (or
something along those lines). I'll bet the same ones are always
broken, right?
I'll bet you have some image files that are just crapped up from the
start, I mean just the plain files right there on the disk! I'll bet
they are corrupted, and the reader is working just fine.
???
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org