On 10/05/2015 11:57 AM, Magnus Hagander wrote:
>
>
> On Sat, Oct 3, 2015 at 7:42 PM, Amir Rohan <amir.rohan@zoho.com
> <mailto:amir.rohan@zoho.com>> wrote:
>
> Hi Magnus,
>
> On 10/03/2015 07:31 PM, Magnus Hagander wrote:
> > On Fri, Oct 2, 2015 at 7:29 PM, Amir Rohan <amir.rohan@zoho.com <mailto:amir.rohan@zoho.com>
> > <mailto:amir.rohan@zoho.com <mailto:amir.rohan@zoho.com>>> wrote:
> >
> > In some email-clients, when you copy the Message-ID to the clipboard
> > it surrounds in (or perhaps, doesn't strip) angle brackets.
> > When pasting this into the mail archive search, search fails to find
> > the message
> > patch attached.
> >
>
> The search works. Meaning the API returns "this messageid exists", which
> causes the search client to send a redirect to an URL that still has the
> non-stripped version of the URL (including the < or space).
>
> The regexp used for parsing URLs only allows either "msgid" or
> "<msgid>". Any other of those combinations will result in a 404 at the
> receiving end of that redirect.
>
> <...>
>
> So either the API needs to be updated to return the actual URL, and the
> consumers (which at this point I believe are just the main website) need
> to be updated to actually use that URL, or the consumer also needs to be
> updated with the same "cleaning" rules, or the URL parsing in the
> archives code need to also deal with all those cases.
>
> I think either the first, or a combination of first and third, of those
> are the way to go. The second one (doing the same changes in the pgweb
> code) seems to just put us in a position where we'll make the same
> mistake again next time we try to fix these rules.
>
With these patches (now touching pgweb and pgarchives, when a (cleaned)
search query gets a hit on a msgid we now include the canonical
messageid in the JSON response. I didn't have it return a url as you
suggested because archives should know as little as possible
about pgweb's link structure. So pgweb still crafts the redirect url,
only it uses the returned msgid if its present in the response.
A separate patch makes archives notion of where pgweb /search
lives coonfigurable, so devs can test.
As a side note, the ping-pong between archives and pgweb seems too
complicated. The search form should possibly be in pgweb instead of
archives, as all it does is server a form submitting to pgweb's
own /search endpoint, it has nothing to do with archives directly.
I tested as best I could, but there's some stuff missing from
my dev setup and no documentation how get thing running.
Amir