Search squid archive

Re: Dual-stack IPv4/IPv6 captive portal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02.03.15 02:33, Amos Jeffries wrote:

  These people are plain wrong about how the basic protocol works and yet
they are treated with must-accept policies by so many networks.

Yep, one of the really big problems we have is the "it works when we're not using the proxy, so the proxy must be broken" attitude, when almost universally the proxy is working fine and the other software is just plain broken. It's really hard to convince a customer that it really isn't our fault when some app breaks, especially when that app is made by someone like Apple or Google (who, of course, can *never* be wrong!)

The vast majority of our support time is spent figuring out ways to work around busted end-user software, because we know saying "Apple's software is broken, go and talk to Apple" isn't going to work because the likes of Apple have no interest in actually supporting their own customers and somehow this ends up being "our fault". (Not just Apple - lots of other companies are equally bad, although Apple have currently hit a nerve with me due to a lot of debugging I recently had to do with their appstore because they didn't bother to log any errors when things broke, which also seems to be par for the course these days).

  Imagine what would happen if you MUST-accept all emails delivered? or
any kind of DNS response they chose to send you? those are two other
major protcols with proxies that work just fine by rejecting bad
messages wholesale.

Well, you say that, but we also get "it works at home but not at work" complaints when DNS servers start returning broken data. Admittedly we usually seem to be able to not catch quite so much blame for that one, although I'm not sure how. :)

Basically, in my experience, if it works in situation A and not in situation B people will assume that the problem is whatever is different in situation B rather than that both situations are completely valid but their application is broken and can't handle one of them. This becomes a big problem when situation A is the more prevalent one - at that point you either start working around the buggy software, or you lose a customer and get a reputation for selling "broken" stuff.

So whilst I agree with you that in an ideal world we wouldn't work around stuff, we would just report bugs and the broken software would be fixed, in the real world the big mainstream businesses aren't interested in supporting their customers and yet somehow the rest of us end up having to do it for them or it reflects badly on *us*. <boggle>


FWIW, I am always happy to work with other people/companies to help them fix their broken stuff. This has been met with a mix of responses - sometimes they are happy to work with me to fix things, which is great, but sadly not the most common experience. Often I send a detailed bug report, explaining what's going wrong, referencing standards, etc. and get a "you're wrong, we're right, we're not going to change anything" response, which would be fine if they referenced anything to back up their position, but they never do. Many simply ignore the reports altogether. Then we have people like Microsoft, who I've tried to contact on several occasions to report bugs in their public-facing web servers - there are no suitable contact details ever published and I've been bounced from department to department with no one quite sure what to do with someone reporting problems with their _public_ servers and not having some kind of support contract with them (I've got no resolution to any of the problems I reported to them because I've never actually managed to get my report to anyone responsible). I've given up reporting bugs to Apple because they always demand that I spend a lot of my time collecting debug logs, but then they sit on the report and never actually fix it (again, I've never had a resolution to a bug I've reported to Apple, despite supplying them with extensive debugging).


/rant :)

--
 - Steve Hill
   Technical Director
   Opendium Limited     http://www.opendium.com

Direct contacts:
   Instant messager: xmpp:steve@xxxxxxxxxxxx
   Email:            steve@xxxxxxxxxxxx
   Phone:            sip:steve@xxxxxxxxxxxx

Sales / enquiries contacts:
   Email:            sales@xxxxxxxxxxxx
   Phone:            +44-1792-824568 / sip:sales@xxxxxxxxxxxx

Support contacts:
   Email:            support@xxxxxxxxxxxx
   Phone:            +44-1792-825748 / sip:support@xxxxxxxxxxxx
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users





[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux