Joe, Thats very interesting what you say. I answer to your points:
1. Eventually we will have an Nginix server at the front end talking to this server. For development purposes we wanted to try things out locally without the hassle of a large amount of infrastructure and the headache of managing a vast quantity of IT to work out the SQL we need. 2. We will look at Authorization in the headers. Our reading of it was that it was not needed, but happy to be proven completely wrong. 3. Your comment on 200 codes scares me, quite honestly. I had always assumed that the 200 codes meant that things were working correctly. We found a similar situation in express.js where begin and end database transactions were being completely ignored, that combined with complex async sql transaction meant that a delete from table might sometimes come after we have inserted the new data, thereby erasing our new data When we realised that the database transactions were no longer atomic, we simply said enough is enough and wanted to try Mojolicous out. 4. Your point on simplifying the end to end transaction is sound. We had started this with the move to the simplest web server we could make. We realise that curl isn't enough, so we might have to do what you suggest. After spending the last two days (and a lot of the night) beating our heads against a wall, we really wanted a simple suggestion :) The fact you think this is a powerful platform gives us hope. Thanks for the helpful reply. Rob On Wed, Apr 29, 2015 at 1:25 PM, Joe Landman <[email protected]> wrote: > > > On 04/29/2015 08:01 AM, Rob Willett wrote: > >> John, >> >> Yes we looked at that and we tried it and couldn't get it to work either. >> >> We also tried the SecureCors version. >> >> We're struggling to understand why this is so difficult. Many, many >> people use this type of framework on the internet but as far as we can see >> very few people have his issue. There are very few code samples around >> either for us to try with which makes me think that somethings not quite >> right. >> > > This is an issue with Grafana pre-2.0. They finally integrated a > dedicated server, which mirrors what we did to make it work (hide the CORS > dependent system behind nginx). > > [...] > > | >>> >>> $self->res->headers->header('Access-Control-Allow-Origin' => '*'); >>> $self->res->headers->header('Access-Control-Allow-Credentials' => >>> 'true'); >>> $self->res->headers->header('Access-Control-Allow-Methods' => >>> 'GET, OPTIONS, POST, DELETE, PUT'); >>> $self->res->headers->header('Access-Control-Allow-Headers' => >>> 'Content-Type'); >>> | >>> >> >> > Don't you want to include "Authorization" in the Allow-Headers ? > > [...] > > We can see the OPTIONS method being called from the Network >>> debugger under Firefox and it returns 200 which is OK. This is >>> followed by a POST method and that looks OK as it returns 200. If >>> we examine the headers it all 'looks ok' but clearly isn't. We >>> can see that the debugging from the Mojlicious server prints out >>> "Post found" which is what we would expect. >>> >>> < >>> https://lh3.googleusercontent.com/-M5gnpxpeQzI/VUDDNTSXHnI/AAAAAAAAAHE/hgu5HgdWP9Q/s1600/Screen%2BShot%2B2015-04-29%2Bat%2B12.16.00.png >>> > >>> >>> We're sure this is something simple, but after a very long night >>> and far too much coffee we've no idea what the problem is. >>> >>> > I had a similar concept problem with InfluxDB that I had to debug. The > first thing I did is try a working server, and then "replace" it with a > very simple 'nc' command to listen on the port and spit out the received > client request. From there, I wrote a very simple client that generated > that same request (started with Mojo::Client, but for a specific reason, > moved to LWP::UserAgent). > > The failure mode was that both Mojo::Client and LWP::UserAgent were > returning a 200 for the overall request, while the service was erroring out > without actually telling us. It turns out that error propagation in web > services is not simply remarkably bad, it is effectively non-existent, and > that 200, or other completion codes may or may not have to do with the > transport only. This was ... well ... a remarkable observation, as I had > been beating on the "why the heck is this failing" horse for a few days, > including some posts late last year here about extracting error messages > from chunked response queries. Short answer is (and this one hurts), you > can't get this data, with any reasonable expectation of reasonableness, > accuracy, etc. I am sure some will disagree, but we saw this with not a > small number of these web based apps that we were working with trying to > query/extract data/make useful. > > You appear to be caught in a similar situation, albeit with CORS rather > than chunked response. > > I'd recommend starting with a known working server and client. Replace the > server with an nc listening on that port, and dumping output to a file. > Write a client that generates that input (firefox and chrome were > effectively useless as debugging platforms until after I found the issues > and corrected them). Put the original server back in place. Make sure the > client still works. Put your new server in place, make sure the client > still works. > > The upshot of this is we now have a very fast and powerful query tool for > our product. It just works, and we and our end users are happy with it. > > Any suggestions welcomed (including pack it all in and take up >>> fishing). >>> >>> Thanks >>> >>> Rob >>> >>> >>> -- You received this message because you are subscribed to the >>> Google Groups "Mojolicious" group. >>> To unsubscribe from this group and stop receiving emails from it, >>> send an email to [email protected] >>> <mailto:[email protected]>. >>> To post to this group, send email to [email protected] >>> <mailto:[email protected]>. >>> Visit this group at http://groups.google.com/group/mojolicious. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the >> Google >> Groups "Mojolicious" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> Visit this group at http://groups.google.com/group/mojolicious. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Mojolicious" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <mailto: >> [email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> Visit this group at http://groups.google.com/group/mojolicious. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > Joe Landman > e: [email protected] > t: @sijoe > > > -- > You received this message because you are subscribed to the Google Groups > "Mojolicious" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/mojolicious. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
