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
> 
> 

Reply via email to