Smith,
On Jan 24, 2014, at 12:24 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
> Greetings,
>> I came across a scenario that I think needs characterization in the implementor’s guide. The scenario is this: a Printer has IPPS enabled but conventional IPP disabled, and it receives a “conventional” HTTP connection from a client. How should the printer respond?
A HTTP sever can return a 426 status with or without the Expect: 100-continue header in the request. This is already covered in RFC 2817.
Clients that do not support TLS Upgrade will simply treat the 426 status as a hard error.
> ...
> I’m also not sure whether this is really a legitimate scenario. If there are some operations that should never require TLS or any form of authentication (the two are related but not the same) then perhaps the Client will not be upgraded right away, and then will not be expecting a later upgrade, and may leak information “accidentally”. For instance, if the Client does a Get-Printer-Attributes operation request that includes the HTTP/1.1 Expect header, it may get back a HTTP 100 Continue. If it switches to a different operation, like Validate-Job or Create-Job, I think it should once again include the HTTP/1.1 Expect header. This specific recommendation detail is currently not covered in wd-ippig20-20140108.pdf section 8.
Yes, the Client should always send Expect: 100-continue unless it knows the Printer does not support it (which is buggy behavior anyways, but ...)
> Am I off in the weeds? This seems to me like a legitimate concern. If I was a new Client implementor, I’d want to know at what points in the algorithms we cover in section 4 I should be sending an HTTP/1.1 Expect, what points I should be expecting a redirect before sending potentially sensitive information on the wire, etc.
It goes beyond TLS - some IPP operations may require authentication, others may not depending on the policy configured in the Printer. So Clients should always include the Expect header unless they know the Printer does not support it, and that allows the correct things to happen without leaking information the Server wants to be confidential based on its configuration.
Clients, of course, should probably always support TLS and always include the Upgrade header indicating their willingness to upgrade to TLS, at a minimum. And there should be a preference for IPPS when the Printer supports both IPP and IPPS (or at least a way to select that, given the overhead of TLS...)
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair