Hi, We recently stumbled onto this and use WAMimeType because we have WAFile instances (from Seaside-Core).
It appears as if there is a lot of overlap with ZnMimeType. It would have been better for us to use ZnMimeType because we had to map the mime type in a similar way that ZnMimeType >> forFilenameExtension: does. Maybe Seaside-Core should just be built on Zinc? On Thu, Jul 30, 2015 at 4:10 PM, Eliot Miranda <[email protected]> wrote: > Hi Sven, > > wouldn't it be better to raise a resumable exception, eg > ZincMissingHeaderField, that the user can catch and resume supplying the > default type? The problem with defaulting is that it buries bugs and assumes > a default for other anomalous cases. > > Sent from my iPhone > >> On Jul 24, 2015, at 6:35 AM, Sven Van Caekenberghe <[email protected]> wrote: >> >> Mariano, >> >> I committed: >> >> === >> Name: Zinc-HTTP-SvenVanCaekenberghe.435 >> Author: SvenVanCaekenberghe >> Time: 24 July 2015, 3:26:54.851874 pm >> UUID: 329427da-0055-4fd9-a59a-ffc62ae4a1d4 >> Ancestors: Zinc-HTTP-SvenVanCaekenberghe.434 >> >> Modify ZnHeaders>>#contentType so that ZnMimeType default >> (application/octet-stream) is returned when there is an empty content type >> header value, this seems to occur in the wild (thx Mariano Peck) >> === >> >> Now you will get bytes back, the native type for application/octet-stream. >> You can of course do an #asString, use a ZnCharacterEncoder or whatever. >> >> Note that you could also use the extension (as we humans would do): >> >> ZnMimeType forFilenameExtension: 'csv' >> >> But even then, no encoding is specified. >> >> I still think the server's response is plain wrong: it say 'here is data, >> but I won't tell you what it means'. The content-type should be text/plain >> or even better text/csv. I think you should contact the Quandl guys and tell >> them exactly that. >> >> Sven >> >>> On 22 Jul 2015, at 16:55, Mariano Martinez Peck <[email protected]> >>> wrote: >>> >>> >>> >>> On Wed, Jul 22, 2015 at 11:48 AM, Sven Van Caekenberghe <[email protected]> >>> wrote: >>> Hi Mariano, >>> >>> I am pretty sure that 'Content-Type' is a required header that cannot be >>> empty. >>> >>> I imagined..that's why I said that even if it was "server's fault" .... >>> >>> It seems to be in an AWS S3 response, which is pretty weird (maybe you >>> uploaded with an empty one in the first place). >>> >>> No, the file was not updated by me, but from a financial data provider. >>> Just try: >>> >>> ZnClient new get: >>> 'http://static.quandl.com/end_of_day_us_stocks/ticker_list.csv' >>> >>> >>> On the other hand, maybe Zn could be a bit more robust. >>> >>> Yes, I think you should. For example, Curl did work for that very same >>> example. >>> >>> But what should Zn do in this case ? There is no content type that matches >>> nil, maybe application/octet-stream (ZnMimeType default) ? >>> >>> >>> Yes, that's exactly my workaround: >>> >>> ZnEntityReader >> contentType >>> ^ ((self headers includesKey: 'Content-Type') and: [ (self headers at: >>> 'Content-Type') isEmpty not]) >>> ifTrue: [ self headers contentType ] >>> ifFalse: [ ZnMimeType applicationOctetStream ] >>> >>> Probably you can make that prettier :) >>> >>> Sven >>> >>>> On 22 Jul 2015, at 16:15, Mariano Martinez Peck <[email protected]> >>>> wrote: >>>> >>>> Hi, >>>> >>>> I am using Zinc to get the contents of a file. The code works correct in >>>> GemStone (because I think it uses a different/older) version but in Pharo >>>> it throws an error in: >>>> >>>> ZnHeaders >> contentType >>>> ^ ZnMimeType fromString: (self headers at: 'Content-Type') >>>> >>>> The error there is in the #fromString: since " (self headers at: >>>> 'Content-Type')" answers an empty string. >>>> The error inside #fromString is in this line: >>>> >>>> sub := aString copyFrom: main size + 2 to: endOfSub. >>>> >>>> that fails of course since 'aString' is an empty string. >>>> >>>> Curl shows indeed that the url I am getting has an empty content type >>>> defined: >>>> >>>> < HTTP/1.1 200 OK >>>> < x-amz-id-2: >>>> eBymTYeSNAPTsgOYDvpbqj/gIPcPpuSb6F0ca/zVjLUG+P2hLZJy/IbU+4MX42sW >>>> < x-amz-request-id: F82747AD31A40F4E >>>> < Date: Wed, 22 Jul 2015 14:02:00 GMT >>>> < Last-Modified: Tue, 21 Jul 2015 20:42:44 GMT >>>> < ETag: "a9fc27157bca2863a58c331e0eae27fb" >>>> < Content-Type: >>>> < Content-Length: 437013 >>>> < Server: AmazonS3 >>>> >>>> So...while it may be "server's fault" because it may be doing something >>>> wrong, is still need to get it. I haven't found any workaround in Zinc >>>> that it wasn't changing code. >>>> >>>> I am fine with changing code / override if this is a bug and will be fixed >>>> later. But if there is a setting or something I would be glad to know it. >>>> >>>> Thanks, >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> >> >
