hi the whole conversation still looks to me like talking cross-purposes.
What I did understand is going on: a) A client (your browser or a software component) is requesting "test.jpg" from a cocoon based server b) the request does match your pipeline c) your customreader is being called it reads a jpg image and generates a byte stream forming a GIF image. d) the stream is being labeled with mime type "image/gif" e) the data stream is received by the calling client and is deemed to be JPG You already verified: - a and b are happening as expected - c is executed as expected - d is true still all doubts are around "e": is it a GIF or a JPG image byte stream. This can not be told easily from a browser as some browser tend not to follow http mime type information. Thus be aware that a browser might tell you "it is a JPG image" just because it recognized a jpg suffix, while the display component will detect a GIF byte stream that it can handle correctly and you will happily look at an image the browser makes you believe is JPG. Thus, again, what is received at "e"? (not in terms of mime type - but in terms of actual byte stream) A simple test in the meantime would be changing the request to call for "test.gif" and compare the results. And you probably should reconsider your request logic: Requesting JPG and getting GIF troubles a lot of potential clients. Would it be possible to make a request for .gif in the necessary cases. A clean approach would be requesting just "test" (without suffix). However, it has nearly the same pitfalls as using a "wrong" suffix, as there is still lots of software around that assumes knowing what a file must be as long as it knows the suffix. Regards, Rainer Gaurav Kalia schrieb: >> What, exactly, comes back to the browser ? > 2) A correct JPEG image, visibile on the browser > >> Moreover, a look at the HTTP headers (both request and response) will >> help sorting this out > I will look into the header and will post it here. >> I don't see the point of a client requesting a JPEG image and >> receiving a GIF one instead > > This is because in my CustomReader i am modifying the image like > converting a rectangular image into circular image and making the rest > of the part other then the circular image transparent and JPG images > does not transparency i guess. > > This is the reason i am converting the JPG image into GIF. > > Regards > Gaurav > > > > > > Luca Morandini wrote: >> On 22/10/09 16:19, Gaurav Kalia wrote: >>> Yes, On the browser the image is coming as JPG format but it should come >>> as GIF Format as transformed by my CustomReader Class. >> >> What, exactly, comes back to the browser ? >> >> 1) A GIF image mistaken for a JPEG one, hence appearing as a broken >> image on the browser >> 2) A correct JPEG image, visibile on the browser >> 3) A correct GIF image, but with the mime-type of a JPEG >> 4) Other... >> >> Moreover, a look at the HTTP headers (both request and response) will >> help sorting this out. >> >> To be honest, I don't see the point of a client requesting a JPEG >> image and receiving a GIF one instead... but I suppose it makes a >> business case of sort. >> >> Regards, >> >> -------------------- >> Luca Morandini >> www.lucamorandini.it >> -------------------- >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Rainer Pruy Geschäftsführer Acrys Consult GmbH & Co. KG Theodor-Heuss-Str. 53-63, D-61118 Bad Vilbel Tel: +49-6101-98760-0 Fax: +49-6101-98760-50 Web: http://www.acrys.com - Email: [email protected] Handelsregister: Frankfurt am Main, HRA 31151 Komplementärin: Acrys Verwaltungs GmbH Theodor-Heuss-Str. 53-63, D-61118 Bad Vilbel Handelsregister: Frankfurt am Main, HRB 57625 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
