Skip to content

Store enclosure metadata without fetching remote URLs - #175

Open
snoopdave wants to merge 1 commit into
masterfrom
enclosure-metadata-entry
Open

Store enclosure metadata without fetching remote URLs#175
snoopdave wants to merge 1 commit into
masterfrom
enclosure-metadata-entry

Conversation

@snoopdave

Copy link
Copy Markdown
Contributor

Summary:

  • collect enclosure media type and byte length alongside its URL
  • validate HTTP(S) enclosure metadata locally before saving
  • populate enclosure metadata from uploaded media files
  • remove the legacy remote metadata lookup classes

Testing:

  • mvn -pl app -Dtest=EnclosureMetadataTest test
  • mvn -V -ntp install (Temurin JDK 11.0.31)

@mraible mraible left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed. Please address the validation compatibility issues and output-handling notes before merge; several existing entries and intranet installations would otherwise be unable to save.

getBean().getEnclosureType(),
getBean().getEnclosureLength());
} catch (IllegalArgumentException e) {
addError("weblogEdit.enclosureMetadataInvalid");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fatal where the old flow was advisory (addMessage and continue), and existing entries can't pass it: the removed MediacastUtil stored con.getContentType() verbatim, so att_mediacast_type may be audio/mpeg; charset=utf-8 or video/mp4;codecs=avc1, which MEDIA_TYPE rejects. The author then can't save any change to that entry until they notice and hand-edit the type. Either accept parameters in the regex (and strip them), or treat an invalid legacy value as "clear the enclosure and warn" instead of refusing the save. Also, one generic message for three fields: a blank Length (new field, previously auto-filled) produces the same text as a bad URL.

getBean().getEnclosureLength());
} catch (IllegalArgumentException e) {
addError("weblogEdit.enclosureMetadataInvalid");
return INPUT;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This returns before the if ("entryAdd".equals(actionName)) getBean().setStatus(null) reset at the end of the method (line 309), which every other failed save on a new entry goes through. publish() has already stamped PUBLISHED on the bean, so the form re-renders with the green "Published (Last updated: )" badge and an empty date for an entry that was never written, and the hidden bean.status carries PUBLISHED into the next submit.

}
if (!MEDIA_TYPE.matcher(normalizedType).matches()) {
throw new IllegalArgumentException("Enclosure type must be a valid media type");
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: no upper bound; Long.MAX_VALUE is accepted and the feed advertises an 8 EiB enclosure. The form caps the field at 20 characters, so a sanity ceiling here would match.

weblogEdit.mediaCastUrlMalformed=The enclosure URL was malformed.
weblogEdit.mediaCastResponseError=The enclosure server returned an error. Do you have the right URL?
weblogEdit.mediaCastLacksContentTypeOrLength=Unable to use enclosure URL. Server provided no content type or no length.
weblogEdit.enclosureURL.tooltip=Absolute HTTP or HTTPS URL to embed within the RSS & Atom feeds for this blog entry.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: the four removed weblogEdit.mediaCast* keys are still in the _de / _es / _fr / _ja / _ko / _ru / _zh_CN bundles, and the ja / zh_CN tooltips still describe the old "podcast URL" semantics rather than the HTTP(S)-only requirement that now produces the error.

@apache apache deleted a comment from mraible Sep 1, 2026
@apache apache deleted a comment from mraible Sep 1, 2026
@apache apache deleted a comment from mraible Sep 1, 2026
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

Successfully merging this pull request may close these issues.

2 participants