beargit vulnerability that allows remote code execution when handling large filenames/paths -- please please please upgrade both your server side and client side git version to 2.7.3 or better
bear[kevinmarks] you may need to run brew doctor and also upgrade homebrew itself to get the version that knows how to handle the OSX permissions change that happend in elcapitan
LoqiThat! (or "that ^" or "that ^^^") is a rarely seen reply often emphasizing agreement with a This post, but sometimes[1] merely emphasizing agreement with a previous reply http://indiewebcamp.com/that
aaronpkin the mean time, i gotta fix my micropub endpoint which i inexplicably broke between last night and this evening despite not changing any micropub endpoint code today
aaronpkat the last minute today, I upgraded a bunch of libraries i was using. I did check whether there were any updates bigger than a patch release (http://semver.org/) and there were none, so I thought everything would be fine.
aaronpkbut it turns out in a patch release, Laravel decided to subclass the Symfony UploadedFile class, which was how I was detecting whether there was a file in the micropub request.
aaronpkit just feels like an overwhelming task to write full tests for my whole site. I much prefer writing tests for specific libraries I'm using because they are easier to wrap my head around.
aaronpkthis all came up because I was trying to change the way I displayed event dates, which is handled by a library, so I pushed out a new version of that library
aaronpkwell there were two fails. client side i was seeing memory warnings, and sometimes the "app" would just stop, but not crash with anything in particular
aaronpkat one point I did get a full-res version onto the server, but it didn't multipart-decode properly so the server rejected the file. pretty sure that was also a client-side fail, since i've uploaded large photos like that other ways
aaronpkif the webmention says target=http://example.com then you look for that literal string on the page, and it's considered invalid if the page contains the string http://example.com/
aaronpkgRegorLove: the only problem with preg_match is you can end up matching text that isn't actualyl in the HTML, like inside an HTML comment for example
KevinMarksso thta may be an optimization. If you find the actual URL in the text, assume it's good. If you don't and they're same domain, do the more complex parse?
voxpelliwith my structure I have separated out the parsing of the page from the matching so all data is already parsed and done when the matching occurs
aaronpkyeah the trick is i don't want to show a tombstone post on my home page when i delete something there, so it's almost like i need a separate URL that can show changes that the reader can consume
aaronpki was thinking a separate page that lists changes, so I could make an update to an old post, and then show that post in this separate page. and if i deleted something, would include a tombstone of it there
voxpellidepends on whether one interprets the PuSH "topic" as strictly the HTML in the topic URL or as the resource represented by the URL. I would say the latter
aaronpke.g. my topic url is https://aaronparecki.com/ and I want to update a post that appears on the third page, but I don't want to re-order the posts on my home page
voxpelliif you push just the updated post then the client should update any existing instance of that post or else add a new one with all data, oncluding original post date, and sort correctly
voxpellithe topic in itself just represents a resource I think – and such a resource can represent ones entire blog, so it probably already is pretty much a wildcard
voxpellione could argue that if the post is so old that it doesn't appears in ones feed, then it's not very likely to be updated or deleted, so in practice it's rarely a problem for a dedicated feed
voxpellisingpolyma: is gnusocial using XML or JSON activitystreams btw? I think one major obstacle for tombstoning in older status.net was that PuSH didn't support them
voxpellifor h-feeds it would be nice with an h-entry with a dt-deleted property or similar + a way to broadcast such a change if the post has dropped of ones frontpage
voxpelliI'm thinking that one should do PuSH-pings whenever ones resource is updated – no matter if something is added to it, changed or deleted from it
voxpelliI'm thinking that this applies to any rel-next/rel-prev page – one should be able to subscribe to all pages as a whole and get notified what single page/part it is that has been affected
voxpelliso that a ping would have rel=self to indicate its context, the topic that the update comes from, and rel-canonical to indicate the preferred URL to fetch the pushed resource from
voxpelliwell, canonical is specced like "Designates the preferred version of a resource (the IRI and its contents)." and self is specced like "Conveys an identifier for the link's context."
voxpelliaaronpk: rel-canonical only states which URL is the preferred version of the URL of your third page, the pagination you would indicate in your HTML with rel-start/rel-next/rel-prev, no?
aaronpkit seems there are essentially two different ways of handling this, so i'd be curious to write them both down and getting feedback on them from others who are actually building readers and publishers
aaronpksince you don't fetch the post URLs, in order to delete a post in woodwind, there would need to be a placeholder in the feed that indicates it's deleted, right?
aaronpki retract my previous preference for u-deleted pointing to the post's URL. dt-deleted + url makes sense, however there still may be a desire/need to indicate a post is deleted without specifying the datetime of when it was deleted.
kylewmaaronpk: i guess the alternative would be having the reader subscribe for updates to each indiviaul post, like voxpelli was suggesting earlier (I think, got confused on the rel-canonical stuff)
voxpelliif it requires extra subscriptions then very few will likely bother to support it, but if they get the notifications anyway, then making something usable of them is a very minor addition, so I think dt-deleted/u-deleted makes sense for feeds
aaronpkyeah subscribing to each individual post seems unlikely to happen, although another benefit of that would be you could show comment threads and update like/repost counts easily
kylewmhmm, not including required information in slugs doesn't help the delete question i had earlier. if i post kylewm.com/2016/03/16/b1/sensitive-info and then later issue a delete for kylewm.com/2016/03/16/b1, the reader won't know those are the same unless I redirect, and then I have the same problem as before