← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/transport/smart.py

Changes prompted by j-a-meinel's review.

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/transport/smart.py
47
47
and the server can expand them.  This will proably not be meaningful when 
48
48
limited to a directory?
49
49
 
50
 
At the bottom level socket, pipes, HTTP server.  For sockets, we have the
51
 
idea that you have multiple requests and get have a read error because the
52
 
other side did shutdown sd send.  For pipes we have read pipe which will have a
53
 
zero read which marks end-of-file.  For HTTP server environment there is not
54
 
end-of-stream because each request coming into the server is independent.
 
50
At the bottom level socket, pipes, HTTP server.  For sockets, we have the idea
 
51
that you have multiple requests and get a read error because the other side did
 
52
shutdown.  For pipes we have read pipe which will have a zero read which marks
 
53
end-of-file.  For HTTP server environment there is not end-of-stream because
 
54
each request coming into the server is independent.
55
55
 
56
 
So we need a wrapper around pipes and sockets to seperate out reqeusts from
 
56
So we need a wrapper around pipes and sockets to seperate out requests from
57
57
substrate and this will give us a single model which is consist for HTTP,
58
58
sockets and pipes.
59
59
 
67
67
  | bytes.
68
68
  v
69
69
 
70
 
PROTOCOL  (serialisation, deserialisation)  accepts bytes for one
 
70
PROTOCOL  (serialization, deserialization)  accepts bytes for one
71
71
          request, decodes according to internal state, pushes
72
72
          structured data to handler.  accepts structured data from
73
73
          handler and encodes and writes to the medium.  factory for
97
97
  | structured data
98
98
  v
99
99
 
100
 
PROTOCOL  (serialisation, deserialisation)  accepts structured data for one
 
100
PROTOCOL  (serialization, deserialization)  accepts structured data for one
101
101
          request, encodes and writes to the medium.  Reads bytes from the
102
102
          medium, decodes and allows the client to read structured data.
103
103
  ^
193
193
# TODO: SmartBzrDir class, proxying all Branch etc methods across to another
194
194
# branch doing file-level operations.
195
195
#
196
 
# TODO: jam 20060915 _decode_tuple is acting directly on input over
197
 
#       the socket, and it assumes everything is UTF8 sections separated
198
 
#       by \001. Which means a request like '\002' Will abort the connection
199
 
#       because of a UnicodeDecodeError. It does look like invalid data will
200
 
#       kill the SmartServerStreamMedium, but only with an abort + exception, and 
201
 
#       the overall server shouldn't die.
202
196
 
203
197
from cStringIO import StringIO
204
198
import os
235
229
        return None
236
230
    if req_line[-1] != '\n':
237
231
        raise errors.SmartProtocolError("request %r not terminated" % req_line)
238
 
    return tuple((a.decode('utf-8') for a in req_line[:-1].split('\x01')))
 
232
    try:
 
233
        return tuple((a.decode('utf-8') for a in req_line[:-1].split('\x01')))
 
234
    except UnicodeDecodeError:
 
235
        raise errors.SmartProtocolError(
 
236
            "one or more arguments of request %r are not valid UTF-8"
 
237
            % req_line)
239
238
 
240
239
 
241
240
def _encode_tuple(args):