Konstantin Ryabitsev <[email protected]> wrote: > HTTP/1.1 300 Multiple Choices > > However, this seems to happen for all unknown message-ids (e.g. > lore.kernel.org/all/bogus@bogus), so probably entirely unrelated.
Yeah, unrelated, it's always returned 300 since I wanted to highlight the fact there's many hosts out there which understand Message-IDs. I just posted a few more patches, one which may help detect missing blobs: https://public-inbox.org/meta/[email protected]/ (I don't know if you log the output of extindex, I don't :x) mid:[email protected] a10c4087bee4dd10eee64903de80ca5c9c064db2 ad29c5999a31edcbbed722b0d8299bf4f72bcae7 mid:[email protected] 910d8e8beb3f5c692c4ba9522f6e22819cce69fb doesn't show up in l.k.o/all/ either... So I wonder if there was a blob reachability problem during indexing. Btw, unlikely to matter, but are you using boost on either regressions or linux-wireless? -- unsubscribe: one-click, see List-Unsubscribe header archive: https://public-inbox.org/meta/
