Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

validation of content types which are not recognized by karman #15

Open
phibo23 opened this issue Jul 15, 2016 · 0 comments
Open

validation of content types which are not recognized by karman #15

phibo23 opened this issue Jul 15, 2016 · 0 comments

Comments

@phibo23
Copy link
Contributor

phibo23 commented Jul 15, 2016

I have a class with a constraint on attachment contentType which includes docx (application/vnd.openxmlformats-officedocument.wordprocessingml.document). That works perfectly fine when creating instances but updating instances fails because contentType is suddenly "application/octet-stream". The file is stored in the local file system.

I had a look into the selfie code and I think I understand the problem but I'm not sure how to fix it:

When creating, the contentType of the uploaded file is determined by this line of code. The file object is an instance of org.springframework.web.multipart.MultipartFile (or org.springframework.web.multipart.commons.CommonsMultipartFile in older versions of selfie), which returns the correct content type for docx.

However, when updating, the content type is determined by this line of code. In this case the getContentType method of Karman's LocalCloudFile class is used and eventually returns a lookup in this map where in fact docx is missing.

So I think this is a two part problem:

  1. selfie should use the same methods for content type determination on safe and on update in order to achieve consistent behaviour.
  2. Karman's mime type list needs to be extended. I looked up the type for docx in this list http://www.freeformatter.com/mime-types-list.html#mime-types-list

PS: I contributed a fix for a similar problem in selfie some time ago which I now think should actually have been applied at the root of the problem

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant