Error/Warning for unescaped filenames in manifest

[kmaginot]

Hi,
I've noticed that Epubcheck emits the warning "Filename contains spaces, therefore URI escaping is necessary. Consider removing spaces from filename." (PKG_010) for filenames containing spaces, but does not produce an error if these filenames are not URI-escaped when they are referenced in the manifest.

Apple Transporter will reject epub files with unescaped spaces in paths in the manifest (but does not mind spaces in the actual filenames as long as they are escaped in the manifest), so it would be great if you could consider adding this as a validation error.

Please see the attached file for an example (Github does not allow epubs, therefore renamed to .zip)
alice.zip

Many thanks!

[vlfors]

Hi all! I’m doing this the task. After the fix some tests have begun to fall. Most of these tasks I know how fix, but test “interesting_paths_epub2” no have check parameters. It needs change package. It is permissible?

[rdeltour]

I'm finally looking into this (sorry for the late answer!). Unfortunately I couldn't reproduce: with alice sample EPUB, EPUBCheck does report the spaces as PKG_010:

alice.epub: Errors: 0; Warnings: 2
WARNING: alice.epub:OEBPS/chapter 1.html: Filename contains spaces, therefore URI escaping is necessary. Consider removing spaces from filename.
WARNING: alice.epub:OEBPS/chapter 2.html: Filename contains spaces, therefore URI escaping is necessary. Consider removing spaces from filename.

I'm closing as invalid. Feel free to reopen if the issue persists on your side or if you think I misinterpreted it!

[mattgarrish]

Isn't the problem that epubcheck warns that the filenames should be URI escaped, but then doesn't report that the names are used without URI escaping in the package document?

The warning doesn't go away if you percent encode the spaces in the manifest entries, so I'm assuming the package document is not where the warning is coming from (if it is, it's confusing that it references the files themselves with line and offset of -1,-1).

[rdeltour]

Oh right I see. I assumed the warning came from the OPF, but yes you're right it doesn't go away when the URLs are properly encoded there.

Isn't it a bit overzealous to report these as warnings however?

In any case, yes a check should be added to report the non-escaped URI in OPF: I assume that should be an error, correct?

[rdeltour]

Isn't it a bit overzealous to report these as warnings however?

I mean, as far as I understand this only comes from a Note, saying:

Authors (…) might find it is best to restrict their File Names to the [US-ASCII] range.

[mattgarrish]

Isn't it a bit overzealous to report these as warnings however?

There was a long discussion about banning spaces in file names during 3.1 because they tend to cause problems, but we decided not to. That sprang up because we had some examples in OCF where the container.xml references had spaces that weren't percent encoded. Did this warning maybe spring out of that discussion?

The lack of URI encoding is definitely a problem that needs reporting, but if we implement that then I'm not sure it matters that we also warn about the file names themselves - at least not until OCF makes some statement about their status.

[rdeltour]

OK, so I suggest:

• keep the WARNING when a file name contains spaces (PKG_010), and change the message to "File name contains spaces, which is discouraged.". The message’s location is the resource which file name is in question (and column/line -1).
• add a new check for the OPF item elements, and report an ERROR when the URI is not properly escaped. The message’s location is the OPF item element.

@mattgarrish OK for you?

[mattgarrish]

Sure, that works for now. Let me reopen that issue and see if we can get better guidance within the spec.

[rdeltour]

The URI parsing aspect is covered since #1396. The warning on non-recommended character will be dealt in #1384. Closing.