4 ms·
Could also be a compliance thing where they were told "If it's not on the form, don't implement it". And it's up to the requestor to specify everything they wan
by Johnny555 11y ago
Could also be a compliance thing where they were told "If it's not on the form, don't implement it". And it's up to the requestor to specify everything they want opened. Having the network team second-guess what was requested could leave unwanted security holes when they have to make assumptions about a request.
Though I don't understand the problem you experienced -- HTTP runs over a bidirectional TCP connection, if they got your request, then packets for that session were already flowing in both directions (the TCP session wouldn't set up otherwise). The only way I could see what you described would be if they had a proxy or some sort of deep inspection firewall in the middle that was blocking the return response.
- nucleardog 11y ago> Could also be a compliance thing where they were told "If it's not on the form, don't implement it". And it's up to the requestor to specify everything they want opened. Sure thing, do exactly what you're told. That doesn't preclude you from firing back a message to say "Hey, this request is unusual and almost certainly wrong, are you sure this is what you wanted?" When a nurse sees an order for 10000 mg of a drug that's never normally administered above 200mg, it's not their job to correct anything, but it is their job to ask the doctor "Hey, did you mean to write 100.00mg? Is this actually correct?"
- DrJokepu 11y agoI get the compliance thing but surely in cases where they can see that a request is very likely to be wrong I don't think it would be unreasonable to expect them to send off an email or give you a call to double check if it is really what you wanted.
- hockley 11y agoThis is not surprising given IBM developed the Consulting Industry Complex standard for blaming the client for failure: The Rational Unified Process.