Error page when trying to access submission with unusual file extension

[Jefficus]

While testing my new HP-powered submission queue, I mistakenly submitted a story file that has an unusual file extension, and now when I try to open that submission on my site, I get:
ERROR: HeyPublisher POST ERROR Code : 410
BAD RETURN: get_submission_by_id()

The file is plain text, in a customized markdown format, and is named with the nonstandard .jd extension. I assume the problem is that HP doesn't know what to do with a .jd file, so it's choking when trying to display it.

For reference, the filename is Sc1.jd, and it was submitted to All These Shiny Worlds Anthology Series.

[Jefficus]

A bit more information:

The submission was made through the HP submission form plugin on my site, which did not seem to check file extensions at submit time. I have since withdrawn that original submission (using the HP site) and submitted a new version with a .txt extension, which I am now able to open and read in my review system. (This new submission has the gloriously illuminating filename: foo.txt. :-)

[aguywithanidea]

Thanks for the note @Jefficus - trying to reproduce now.

[aguywithanidea]

Found the problem.

This is being caused by code on the server side that takes the uploaded file and converts it to HTML for display within the plugin. The uploader looks at the content-type of the file and ensures that it's one of the allowed types before sending the file on for conversion. The converter on the other hand, looks at file extension when it doesn't know what to do with the content-type.

In cases where the content-type is known (ie: application/rtf) and the file type is unknown or not set, this is not a problem.
The converter will determine what it's supposed to do from the content-type.

In cases where the content-type is less clear (ie: application/octet-stream) the converter is highly dependent on the file extension to know how to start.

This is the issue here - the content type of the file is application/octet-stream and the file extension is .jd. The content-type is allowed by upload, as this is the content-type used by a lot of open source text editors, but then the converter croaks because it doesn't know what to do with the .jd extension.

I've fixed this on the server side by adding an additional uploader check on the file extension to ensure it's one the known file types the converter can deal with when content-type is application/octet-stream.

This fix will be pushed out with the next server code release, sometime before September 1st. An upgrade of the plugin will not be required to support this change.

I will close this issue out when the code has been released.

[Jefficus]

Sounds like a reasonable solution. I'll give it a try once the new version pushes. Thanks.

[aguywithanidea]

Update: Server code has been updated. Will require a new server environment to be built, which is currently scheduled to occur over Labor Day weekend (Sept 4th-6th).