-
|
Hi! Not quite sure on which side this should be fixed... CKAN: 2.9.1 The issue is whenever a csv-file is added to datasets, it creates a request for datapusher to download it from CKAN. CKAN sends HTTP 302 with the redirection URL pointing to Giftless (http://127.0.0.1:9419/ in the screenshot). Then Giftless responses with the file content but sends the wrong Content-type, text/html instead of text/csv, this in turn causes a crash inside datapusher:
If content-type is set in ad-hoc manner to the correct one i.e. text/csv, then datapusher works nicely. But I guess it is probably Giftless responsibility to give the correct document type as content-type (?) And the ultimate resulting problem is that csv-files are not previewed in CKAN UI.
Any help in resolving this is highly appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
What storage backend are you using (assuming local / streaming based on the info)? Not all backends support properly sending content-type headers. To give some background, Content-type is not somethnig handled by the Git LFS protocol (typically this isn't needed by Git LFS). Some of the storage backends supported by Giftless have extra functionality to handle content-type headers, but local storage doesn't store information about the content type anywhere, and so adding support for it can be done but might require some guessing or extension of the protocol. This was briefly discussed here: #68 but nothing was done to handle content-type, just content-disposition header. In any case if you want this supported, it should be reported as a new issue / feature request. |
Beta Was this translation helpful? Give feedback.
-
|
Here is how my original specs from gifteless.yaml for storage:
Based on your reply I tried I think it should be more clearly stated in the documentation |
Beta Was this translation helpful? Give feedback.
-
|
Glad to know you have a solution, in general using the |
Beta Was this translation helpful? Give feedback.
What storage backend are you using (assuming local / streaming based on the info)? Not all backends support properly sending content-type headers.
To give some background, Content-type is not somethnig handled by the Git LFS protocol (typically this isn't needed by Git LFS). Some of the storage backends supported by Giftless have extra functionality to handle content-type headers, but local storage doesn't store information about the content type anywhere, and so adding support for it can be done but might require some guessing or extension of the protocol. This was briefly discussed here: #68 but nothing was done to handle content-type, just content-disposition header.
In any case if you…