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 <sven@stfx.eu> 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 <marianopeck@gmail.com> wrote:
On Wed, Jul 22, 2015 at 11:48 AM, Sven Van Caekenberghe <sven@stfx.eu> 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 <marianopeck@gmail.com> 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