On 8 Jan 2009, at 17:51, Jonathan Rochkind wrote:
We have contracts with literally hundreds of such providers.
Most of which do the right thing.
This one provider in particular that sends the bad URL is a
particular large company (EBSCO), with billions of dollars in
revenue, and thousand
On Thu, Jan 8, 2009 at 18:51, Jonathan Rochkind wrote:
> I can scream to the rooftops all I want. [...]
>
> I complained both privately and publically about this. But the world is not
> always as we would like it, and sometimes our software needs to deal with
> incoming data that is not standard
I can scream to the rooftops all I want. This particular product I am
working on is an OpenURL Resolver that handles OpenURLs representing
scholarly citations sent from third-party licensed search providers that
the library (where I work) pays for. We have contracts with literally
hundreds of
On 7 Jan 2009, at 21:31, Jonathan Rochkind wrote:
Yes, the third party sending me this information in a query string
was doing it in a way that was illegal and violated standards, but
they are more powerful than I, and I can not make them change their
behavior, and I need to handle those U
This particular case actually doesn't bother me in particular. It may
be fine for "/%" to be a 400 rather than a 404.
My particular case involved needing to process mal-formed query strings
sent by third parties. I had no control over these third parties. I
_needed_ to be able to process quer
> Has anyone got it to work so Nginx will use an actual error page instead
> of the default when encountering a Bad Request?
This is pretty easy to do, just use the "error_page" directive and
list all of the ones you want to capture and then specify it to use
your 500 page, e.g. we capture all 5xx
> On the other hand, does Apache not allow configuring the page returned
> for 400 Bad Request. This would
> then also allow addressing the issue that
I'm using Nginx and it does allow you to set error_pages, but that
doesn't seem to work in this case (at least for me).
Has anyone got it to work
Stephan Wehner wrote:
It strikes me as a good thing that Apache weeds out bad URL's. Less
parsing for mongrel, less work, and one less point of failure to worry
about. (When I see code like above after "Turn off buffering" - with
all respect - I get worried.)
Um, that code that worries you is
On 1/7/09, Jonathan Rochkind wrote:
> Yes. I have run into this before. Mongrel will error on an invalid HTTP URI,
> with one common case being characters not properly escaped, which is what
> your example is. When one of the developers of my app brought this up
> before, he was told by the Mongr
On Wed, Jan 7, 2009 at 12:06 PM, Jonathan Rochkind wrote:
> Yes. I have run into this before. Mongrel will error on an invalid HTTP URI,
> with one common case being characters not properly escaped, which is what
> your example is. When one of the developers of my app brought this up
> before, he
Yes. I have run into this before. Mongrel will error on an invalid HTTP
URI, with one common case being characters not properly escaped, which
is what your example is. When one of the developers of my app brought
this up before, he was told by the Mongrel developer that this was
intentional, a
So how do you catch it? All of those errors are not very friendly and
completely bypass the site look and feel.
See these:
http://www.google.com/%
http://www.yahoo.com/%
Robbie
Stephan Wehner wrote:
> On Wed, Jan 7, 2009 at 11:44 AM, Robbie Allen
> wrote:
>> but is there anyway to have mo
On Wed, Jan 7, 2009 at 11:44 AM, Robbie Allen wrote:
> If you append an extra percent sign to a URL that gets passed to
> mongrel, it will return a Bad Request error. Kind of odd that
> "http://localhost/%"; causes a "Bad Request" instead of a "Not Found"
> error.
>
> Here is the error from the m
If you append an extra percent sign to a URL that gets passed to
mongrel, it will return a Bad Request error. Kind of odd that
"http://localhost/%"; causes a "Bad Request" instead of a "Not Found"
error.
Here is the error from the mongrel log:
HTTP parse error, malformed request (127.0.0.1):
#
I
14 matches
Mail list logo
