Should parse fail when a parameter has non-decodable field?

[alexstrat]

Related to #13

Should parse fail when content-disposition header contains a parameter which field is not decodable ?
Today it fails. Shouldn't it only ignore the parameter and move on ?

• what specifically would be considered a recoverable parse failure vs an unrecoverable failure ?
• what should be returned when various different recoverable failures occur ?
• how can we keep intact a strict mode for any users who would want a complete failure ?
• what, if any, guidance does the RFC have on this ?

[dougwilson]

Hi @alexstrat would you be willing to fill in your answers? My answers to those questions have already been codified into this module; they were more questions I was hoping you could answer to help me understand the request you're making.

[alexstrat]

Ah sorry, did not get the extent of your questions. As far as I was concerned, I only used the library to make the difference between a download (attachment) and regular web-pages: I think it's a pretty limited use-case and is not representative of what one can extensively expect from this module.

Though:

what specifically would be considered a recoverable parse failure vs an unrecoverable failure ?

For my specific use case, I was only interested in the type. I don't care about the parameters, if they are stripped away, I would not have cared.

what should be returned when various different recoverable failures occur ?

The result of parse, only. Can probably have an option to let parse returns the result with the parse errors.

how can we keep intact a strict mode for any users who would want a complete failure ?

An option of parse I guess.

what, if any, guidance does the RFC have on this?

No idea. While it can be a good enlightenment, I don't think parse should strictly follow the RFC. I'd rather expect from it to be able to parse the best it can a Content Disposition header, whatever this one is RFC-compliant or not.

[dougwilson]

Hi @alexstrat after reading you responses, I'm not sure you really understanding the workings of the header to really give answers, no offense :) Especially if you are suggesting to not even follow the RFC. If we don't follow it, what are we following? If you can provide a spec, perhaps some complete ABNF grammar to how the parse should function in this non-strict mode, that would work, but from what your use-case is, it seems simpler for you to just header.split(';')[0].trim()

[alexstrat]

Oh I'm sorry to see you disappointed by my answers :(

I think the question is still open though.

[dougwilson]

Sure, but there isn't really a description to program against. For example, a regular expression either returns a result or not, so "The result of parse, only" would always be no result on a failure, probably not what you're looking for. If we don't follow the RFC, what are we following? If you can provide a spec, perhaps some complete ABNF grammar to how the parse should function in this non-strict mode, that would work.