#musicbrainz-devel

:-(

ocharles has changed the topic to: Agenda: Release editor testing

Hum, no ijabz

djce: I have some rewrite rules for nginx, but I'm not sure how I can test them

https://gist.github.com/1117864 is what I think is correct

I think you're missing a "^" in the regexp on line 3, no?

But as for testing... do you have an nginx on hobbes?

yea, there's nginx on hobbes

If so, drop the rules in there, kick nginx, test using curl/lwp-request/whatever

Or am I missing something?

oh, request to test.musicbrainz.org and pretend to be requesting www.musicbrainz.org?

something like that, yes

but tbh, that rule would redirect test.musicbrainz.org anyway

not sure if you /want/ it to, but I think that's what it will do

Well I'm only going to commit this to the production branch

I thought we wanted to redirect get, not post?

Yea, that should be !=

and it doesn't seem "&&" works in if :/

http://wiki.nginx.org/NginxHttpRewriteModule#if has server { server_name www.example.com; rewrite ^ http://example.com$request_uri? permanent; }

so maybe that would work instead of the http host bit... then an if for the post bit... but I'm not sure why exactly libmusicbrainz is excluded

because it can't handle redirects

heh... http://wiki.nginx.org/RewriteMultiCondExample

yum, hacky!

ewwwwww!

djce: is that a "please dont put that mess in nginx config!" ewww? :)

Your config, you do what you like ;-)

but no, it's a "really? Is that the only way" ewww

yea, kinda sucky but still easier than getting it into the perl

would be easier in perl if we running under PSGI, but we aren't

why are you planning to make a special rewrite rule for libmusicbrainz?

or, it *not* libmusicbrainz

still weird

luks: because it can't handle redirects

I'm just trying to copy what we had before

ocharles: then it should be fixed

well I assume libmusicbrainz4 doesn't have that problem

besides, I think the apache rewrite config is pretty old

from what I can see, lmb3 uses neon, which i'm not sure follows redirects for you

I think it does, but I'd remove the special case even if it doesn't

I'm happy to leave that extra logic out though...

are you doing this for *.musicbrainz.org or just www.musicbrainz.org?

Hello!

hi enjayhch!

note that there is mm.musicbrainz.org, which probably shouldn't be redirected

hm, I could have sworn it used to redirect

new version of /music site is nearly ready to go live

enjayhch: awesome!

luks: I'm going to just rewrite www in this simpler rewrite

not really any new exciting features

just re-written for new platform and re-skin

very squarey

nikki: that would generate a lot of useless traffic, as the older libraries used only mm.mb.org

does anyone know if there is a existing MBS ticket for searching MusicBrainz API by URL?

well I remember seeing programs using it and thinking "huh? what does that do?" and I thought it redirected when I tried it

ie who has the homepage www.madona.com?

there is

(only spelt right)

enjayhch: there is

hah, I was the reporter in Trac

enjayhch: adding your specific use cases as a comment would be great (ie, if you only want to search by domain)

hehe

I might get Paulo to work on it

he is back on Wednesday

cool

oh, the original trac ticket has more details too

ocharles: yup, good idea

djce: how does www.musicbrainz.org get to astro? From what I can see on astro's nginx config, it only has a server { } block for server_name musicbrainz.org;

<sheepish grin>. Well spotted.

Remind me, what's the ticket ID you're working on? Just need to check something.

Well, on astro http://0.0.0.0:80/ also gets served even though I'm requesting Host: 0.0.0.0

Ah, right, just checking. ok, here's what happens,

Requests for any of "musicbrains.org ftp.musicbrains.org www.musicbrains.org"; get unconditionally redirected to musicbrainz.org.

by the front end nginx.

Requests for musicbrainz.org mm.musicbrainz.org www.musicbrainz.org get received by the front end nginx and passed on to the back end (astro), with, AFAICT, the Host header preserved

so you should receive www.musicbrainz.org on astro even though you didn't declare it.

astro seems happy to serve regardless of what the host is

curl -H "Host: waffles.musicbrainz.org" http://0.0.0.0:80 goes through just fine

I think it's like apache: you've only declared one vhost (server { } block)

so anything which doesn't match a declared server's name

goes to the first server

i.e. the only one you've got.

if that makes sense.

ah, makes sense

yea

not quite, http://wiki.nginx.org/HttpCoreModule#server - a bit more predictable

http://codereview.musicbrainz.org/r/1438/diff/#... well, that's what I've come up with

anyone know how long it has been since de.msuicbrainz.org and nl.musicbrainz.org worked?

(ignoring typos)

ocharles: not sure if you've seen the last comment here: http://tickets.musicbrainz.org/browse/MBS-2828 but adding &cdstubs=no 404s /ws/2/discid lookups

Not sure if this belongs here, or on #musicbrainz:

I'm working on a Perl API to the NGS webservice, and am getting to the point where some user feedback would be useful, before I start to document everything.

If there's anyone with an interest in that area, I'd be grateful if you could let me know.

voiceinsideyou1: archive.org suggests 2007 for nl and 2008 for de

I guess those should be removed as hardcoded mirror servers in Picard then ;)

picard seems to have a lot of hardcoded lists :P

only one hardcoded list of hardcoded lists

(I mean, it needs access to a server to fetch info anyway)

like an xml file hosted somewhere on mb?

yeah; put in one option to change it from musicbrainz.org, in case that goes down for some reason or the other

and yeah, XML hosted on MB

or constructed from the database

just a real basic API

yeah

the de.mb.org thing broke Picard for at least one person recently http://bugs.musicbrainz.org/ticket/5980

like medium formats presumably would be auto-constructed, but

I mentioned it the other day when we were talking about translation, since at some point the website will also be translated

so it would be good if we could avoid translating stuff twice

+1

and if picard can fetch the lists from the server, the server can also return the translations too

I wonder how that would work though given that Picard uses gettext

presumably you'd just need access to the locale somewhere

to throw at the API

it means the translation is split (between gettext in Picard and whatever the server uses) but unless picard gets _everything_ from the server that's bound to happen

since picard can't have .po for every release out there :P

ooh, or the API could return pofiles ;)

(that wouldn't be needlessly convoluted at all :P)

for things like medium formats it would probably need the .po files before initializing gettext

yeah

I was figuring it just wouldn't use gettext for those things

since the server could do that translation

(the API returning .po files thing was just a joke)

yeah, I figured :)