Archive for the ‘Architecture logicielle’ Category

Titus Brown

wget http://hg.secdev.org/scapy/raw-file/tip/scapy.py
cp scapy.py /var/lib/python-support/python2.4/

$ cat /usr/bin/scapy
#!/bin/sh
exec /usr/bin/python /var/lib/python-support/`pyversions -d`/scapy.py

aptitude install scapy

urpmi scapy

$ svn checkout http://svn.nuxeo.org/nuxeo/nuxeo-ep/trunk nuxeo-ecm
$ svn checkout https://svn.nuxeo.org/nuxeo/nuxeo-ep/trunk nuxeo-ecm
create table miners (

   id BIGINT NOT NULL AUTO_INCREMENT,

   first_name VARCHAR(255),

   last_name VARCHAR(255),

   primary key (id)

)
class Miner < ActiveRecord::Base

endminer.first_name = "Brom"
/**  * @hibernate.class table="miners"  */
public class Miner
{
private String firstName;
private String lastName;     /**      * @hibernate.id generator-class="native"      */
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }      /**      * @hibernate.property column="first_name"      */
public String getFirstName() { return firstName; }
public void setFirstName(String firstName) { this.firstName = firstName; }      /**      * @hibernate.property column="last_name"      */
public String getLastName() { return lastName; }
public void setLastName(String lastName) { this.lastName = lastName; }
}
miner.setFirstName("Brom");
# describe a table called 'miner',  query the database for its columns

miners_table = Table('miners', meta, autoload=True, autoload_with=engine)
>>> class Miner(object):

...     def __init__(self, first_name, last_name ):

...         self.first_name = first_name

...         self.last_name = last_name

...

...     def __repr__(self):

...        return "<Miner(%r,%r)>" % (self.first_name, self.last_name)
mapper(Miner, miners_table) 
theMiner = Miner(first_name = "Brom")
(Java)

public class Miner {

   // Other fields/methods omitted    private GoldClaim goldClaim;

    /**

     * @hibernate.many-to-one column="gold_claim_id"

     *         cascade="save"

     */

    public GoldClaim getGoldClaim() { return goldClaim; }

    public void setGoldClaim(GoldClaim goldClaim) {

        this.goldClaim = goldClaim;

    }

}
(Rails)

class Miner < ActiveRecord::Base

    belongs_to :gold_claim

end
parent_table = Table('parent', metadata,

    Column('id', Integer, primary_key=True),

    Column('child_id', Integer, ForeignKey('child.id')))

child_table = Table('child', metadata,

    Column('id', Integer, primary_key=True),

    )

class Parent(object):

    pass

 class Child(object):

    pass

 mapper(Parent, parent_table, properties={

    'child':relation(Child)

})

mapper(Child, child_table)
   The GET method means retrieve whatever information (in the form of an
   entity) is identified by the Request-URI. If the Request-URI refers
   to a data-producing process, it is the produced data which shall be
   returned as the entity in the response and not the source text of the
   process, unless that text happens to be the output of the process.

   The semantics of the GET method change to a "conditional GET" if the
   request message includes an If-Modified-Since, If-Unmodified-Since,
   If-Match, If-None-Match, or If-Range header field. A conditional GET
   method requests that the entity be transferred only under the
   circumstances described by the conditional header field(s). The
   conditional GET method is intended to reduce unnecessary network
   usage by allowing cached entities to be refreshed without requiring
   multiple requests or transferring data already held by the client.

   The semantics of the GET method change to a "partial GET" if the
   request message includes a Range header field. A partial GET requests
   that only part of the entity be transferred, as described in section
   14.35. The partial GET method is intended to reduce unnecessary
   network usage by allowing partially-retrieved entities to be
   completed without transferring data already held by the client.

   The response to a GET request is cacheable if and only if it meets
   the requirements for HTTP caching described in section 13
   The DELETE method requests that the origin server delete the resource
   identified by the Request-URI. This method MAY be overridden by human
   intervention (or other means) on the origin server. The client cannot
   be guaranteed that the operation has been carried out, even if the
   status code returned from the origin server indicates that the action
   has been completed successfully. However, the server SHOULD NOT
   indicate success unless, at the time the response is given, it
   intends to delete the resource or move it to an inaccessible
   location.

   A successful response SHOULD be 200 (OK) if the response includes an
   entity describing the status, 202 (Accepted) if the action has not
   yet been enacted, or 204 (No Content) if the action has been enacted
   but the response does not include an entity.

   If the request passes through a cache and the Request-URI identifies
   one or more currently cached entities, those entries SHOULD be
   treated as stale. Responses to this method are not cacheable.
   The PUT method requests that the enclosed entity be stored under the
   supplied Request-URI. If the Request-URI refers to an already
   existing resource, the enclosed entity SHOULD be considered as a
   modified version of the one residing on the origin server. If the
   Request-URI does not point to an existing resource, and that URI is
   capable of being defined as a new resource by the requesting user
   agent, the origin server can create the resource with that URI. If a
   new resource is created, the origin server MUST inform the user agent
   via the 201 (Created) response. If an existing resource is modified,
   either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
   to indicate successful completion of the request. If the resource
   could not be created or modified with the Request-URI, an appropriate
   error response SHOULD be given that reflects the nature of the
   problem. The recipient of the entity MUST NOT ignore any Content-*
   (e.g. Content-Range) headers that it does not understand or implement
   and MUST return a 501 (Not Implemented) response in such cases.

   If the request passes through a cache and the Request-URI identifies
   one or more currently cached entities, those entries SHOULD be
   treated as stale. Responses to this method are not cacheable.

   The fundamental difference between the POST and PUT requests is
   reflected in the different meaning of the Request-URI. The URI in a
   POST request identifies the resource that will handle the enclosed
   entity. That resource might be a data-accepting process, a gateway to
   some other protocol, or a separate entity that accepts annotations.
   In contrast, the URI in a PUT request identifies the entity enclosed
   with the request -- the user agent knows what URI is intended and the
   server MUST NOT attempt to apply the request to some other resource.
   If the server desires that the request be applied to a different URI,

Fielding, et al.            Standards Track                    [Page 55]

RFC 2616                        HTTP/1.1                       June 1999

   it MUST send a 301 (Moved Permanently) response; the user agent MAY
   then make its own decision regarding whether or not to redirect the
   request.

   A single resource MAY be identified by many different URIs. For
   example, an article might have a URI for identifying "the current
   version" which is separate from the URI identifying each particular
   version. In this case, a PUT request on a general URI might result in
   several other URIs being defined by the origin server.

   HTTP/1.1 does not define how a PUT method affects the state of an
   origin server.
   The HEAD method is identical to GET except that the server MUST NOT
   return a message-body in the response. The metainformation contained
   in the HTTP headers in response to a HEAD request SHOULD be identical
   to the information sent in response to a GET request. This method can
   be used for obtaining metainformation about the entity implied by the
   request without transferring the entity-body itself. This method is
   often used for testing hypertext links for validity, accessibility,
   and recent modification.

   The response to a HEAD request MAY be cacheable in the sense that the
   information contained in the response MAY be used to update a
   previously cached entity from that resource. If the new field values
   indicate that the cached entity differs from the current entity (as
   would be indicated by a change in Content-Length, Content-MD5, ETag
   or Last-Modified), then the cache MUST treat the cache entry as
   stale.
   The OPTIONS method represents a request for information about the
   communication options available on the request/response chain
   identified by the Request-URI. This method allows the client to
   determine the options and/or requirements associated with a resource,
   or the capabilities of a server, without implying a resource action
   or initiating a resource retrieval.

   Responses to this method are not cacheable.

   If the OPTIONS request includes an entity-body (as indicated by the
   presence of Content-Length or Transfer-Encoding), then the media type
   MUST be indicated by a Content-Type field. Although this
   specification does not define any use for such a body, future
   extensions to HTTP might use the OPTIONS body to make more detailed
   queries on the server. A server that does not support such an
   extension MAY discard the request body.

   If the Request-URI is an asterisk ("*"), the OPTIONS request is
   intended to apply to the server in general rather than to a specific
   resource. Since a server's communication options typically depend on
   the resource, the "*" request is only useful as a "ping" or "no-op"
   type of method; it does nothing beyond allowing the client to test
   the capabilities of the server. For example, this can be used to test
   a proxy for HTTP/1.1 compliance (or lack thereof).

   If the Request-URI is not an asterisk, the OPTIONS request applies
   only to the options that are available when communicating with that
   resource.

   A 200 response SHOULD include any header fields that indicate
   optional features implemented by the server and applicable to that
   resource (e.g., Allow), possibly including extensions not defined by
   this specification. The response body, if any, SHOULD also include
   information about the communication options. The format for such a

Fielding, et al.            Standards Track                    [Page 52]

RFC 2616                        HTTP/1.1                       June 1999

   body is not defined by this specification, but might be defined by
   future extensions to HTTP. Content negotiation MAY be used to select
   the appropriate response format. If no response body is included, the
   response MUST include a Content-Length field with a field-value of
   "0".

   The Max-Forwards request-header field MAY be used to target a
   specific proxy in the request chain. When a proxy receives an OPTIONS
   request on an absoluteURI for which request forwarding is permitted,
   the proxy MUST check for a Max-Forwards field. If the Max-Forwards
   field-value is zero ("0"), the proxy MUST NOT forward the message;
   instead, the proxy SHOULD respond with its own communication options.
   If the Max-Forwards field-value is an integer greater than zero, the
   proxy MUST decrement the field-value when it forwards the request. If
   no Max-Forwards field is present in the request, then the forwarded
   request MUST NOT include a Max-Forwards field.
   The POST method is used to request that the origin server accept the
   entity enclosed in the request as a new subordinate of the resource
   identified by the Request-URI in the Request-Line. POST is designed
   to allow a uniform method to cover the following functions:

      - Annotation of existing resources;

      - Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;

      - Providing a block of data, such as the result of submitting a
        form, to a data-handling process;

      - Extending a database through an append operation.

   The actual function performed by the POST method is determined by the
   server and is usually dependent on the Request-URI. The posted entity
   is subordinate to that URI in the same way that a file is subordinate
   to a directory containing it, a news article is subordinate to a
   newsgroup to which it is posted, or a record is subordinate to a
   database.

   The action performed by the POST method might not result in a
   resource that can be identified by a URI. In this case, either 200
   (OK) or 204 (No Content) is the appropriate response status,
   depending on whether or not the response includes an entity that
   describes the result.

Fielding, et al.            Standards Track                    [Page 54]

RFC 2616                        HTTP/1.1                       June 1999

   If a resource has been created on the origin server, the response
   SHOULD be 201 (Created) and contain an entity which describes the
   status of the request and refers to the new resource, and a Location
   header (see section 14.30).

   Responses to this method are not cacheable, unless the response
   includes appropriate Cache-Control or Expires header fields. However,
   the 303 (See Other) response can be used to direct the user agent to
   retrieve a cacheable resource.
   Implementors should be aware that the software represents the user in
   their interactions over the Internet, and should be careful to allow
   the user to be aware of any actions they might take which may have an
   unexpected significance to themselves or others.

   In particular, the convention has been established that the GET and
   HEAD methods SHOULD NOT have the significance of taking an action
   other than retrieval. These methods ought to be considered "safe".
   This allows user agents to represent other methods, such as POST, PUT
   and DELETE, in a special way, so that the user is made aware of the
   fact that a possibly unsafe action is being requested.

   Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request; in
   fact, some dynamic resources consider that a feature. The important
   distinction here is that the user did not request the side-effects,
   so therefore cannot be held accountable for them.
   Methods can also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of N > 0 identical
   requests is the same as for a single request. The methods GET, HEAD,
   PUT and DELETE share this property. Also, the methods OPTIONS and
   TRACE SHOULD NOT have side effects, and so are inherently idempotent.

Fielding, et al.            Standards Track                    [Page 51]
RFC 2616                        HTTP/1.1                       June 1999

   However, it is possible that a sequence of several requests is non-
   idempotent, even if all of the methods executed in that sequence are
   idempotent. (A sequence is idempotent if a single execution of the
   entire sequence always yields a result that is not changed by a
   reexecution of all, or part, of that sequence.) For example, a
   sequence is non-idempotent if its result depends on a value that is
   later modified in the same sequence.

   A sequence that never has side effects is idempotent, by definition
   (provided that no concurrent operations are being executed on the
   same set of resources).

14.25 If-Modified-Since

   The If-Modified-Since request-header field is used with a method to
   make it conditional: if the requested variant has not been modified
   since the time specified in this field, an entity will not be
   returned from the server; instead, a 304 (not modified) response will
   be returned without any message-body.

       If-Modified-Since = "If-Modified-Since" ":" HTTP-date

Fielding, et al.            Standards Track                   [Page 130]

RFC 2616                        HTTP/1.1                       June 1999

   An example of the field is:

       If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

   A GET method with an If-Modified-Since header and no Range header
   requests that the identified entity be transferred only if it has
   been modified since the date given by the If-Modified-Since header.
   The algorithm for determining this includes the following cases:

      a) If the request would normally result in anything other than a
         200 (OK) status, or if the passed If-Modified-Since date is
         invalid, the response is exactly the same as for a normal GET.
         A date which is later than the server's current time is
         invalid.

      b) If the variant has been modified since the If-Modified-Since
         date, the response is exactly the same as for a normal GET.

      c) If the variant has not been modified since a valid If-
         Modified-Since date, the server SHOULD return a 304 (Not
         Modified) response.

   The purpose of this feature is to allow efficient updates of cached
   information with a minimum amount of transaction overhead.

      Note: The Range request-header field modifies the meaning of If-
      Modified-Since; see section 14.35 for full details.

      Note: If-Modified-Since times are interpreted by the server, whose
      clock might not be synchronized with the client.

      Note: When handling an If-Modified-Since header field, some
      servers will use an exact date comparison function, rather than a
      less-than function, for deciding whether to send a 304 (Not
      Modified) response. To get best results when sending an If-
      Modified-Since header field for cache validation, clients are
      advised to use the exact date string received in a previous Last-
      Modified header field whenever possible.

      Note: If a client uses an arbitrary date in the If-Modified-Since
      header instead of a date taken from the Last-Modified header for
      the same request, the client should be aware of the fact that this
      date is interpreted in the server's understanding of time. The
      client should consider unsynchronized clocks and rounding problems
      due to the different encodings of time between the client and
      server. This includes the possibility of race conditions if the
      document has changed between the time it was first requested and
      the If-Modified-Since date of a subsequent request, and the

Fielding, et al.            Standards Track                   [Page 131]

RFC 2616                        HTTP/1.1                       June 1999

      possibility of clock-skew-related problems if the If-Modified-
      Since date is derived from the client's clock without correction
      to the server's clock. Corrections for different time bases
      between client and server are at best approximate due to network
      latency.

   The result of a request having both an If-Modified-Since header field
   and either an If-Match or an If-Unmodified-Since header fielfields is
   undefined by this specification

10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is

allowed, but the document has not been modified, the server SHOULD

respond with this status code. The 304 response MUST NOT contain a

message-body, and thus is always terminated by the first empty line

after the header fields.
The response MUST include the following header fields:
- Date, unless its omission is required by section 14.18.1
Fielding, et al.            Standards Track                    [Page 63]

RFC 2616                        HTTP/1.1                       June 1999
If a clockless origin server obeys these rules, and proxies and

clients add their own Date to any response received without one (as

already specified by [RFC 2068], section 14.19), caches will operate

correctly.
- ETag and/or Content-Location, if the header would have been sent

in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value might

differ from that sent in any previous response for the same

variant
If the conditional GET used a strong cache validator (see section

13.3.3), the response SHOULD NOT include other entity-headers.

Otherwise (i.e., the conditional GET used a weak validator), the

response MUST NOT include other entity-headers; this prevents

inconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the

cache MUST disregard the response and repeat the request without the

conditional.
If a cache uses a received 304 response to update a cache entry, the

cache MUST update the entry to reflect any new field values given in

the response.

14.8 Authorization

      A user agent that wishes to authenticate itself with a server--
      usually, but not necessarily, after receiving a 401 response--does
      so by including an Authorization request-header field with the
      request.  The Authorization field value consists of credentials
      containing the authentication information of the user agent for
      the realm of the resource being requested.

          Authorization  = "Authorization" ":" credentials

      HTTP access authentication is described in "HTTP Authentication:
      Basic and Digest Access Authentication" [43]. If a request is
      authenticated and a realm specified, the same credentials SHOULD
      be valid for all other requests within this realm (assuming that
      the authentication scheme itself does not require otherwise, such
      as credentials that vary according to a challenge value or using
      synchronized clocks).

      When a shared cache (see section 13.7) receives a request
      containing an Authorization field, it MUST NOT return the
      corresponding response as a reply to any other request, unless one
      of the following specific exceptions holds:

      1. If the response includes the "s-maxage" cache-control
         directive, the cache MAY use that response in replying to a
         subsequent request. But (if the specified maximum age has
         passed) a proxy cache MUST first revalidate it with the origin
         server, using the request-headers from the new request to allow
         the origin server to authenticate the new request. (This is the
         defined behavior for s-maxage.) If the response includes "s-
         maxage=0", the proxy MUST always revalidate it before re-using
         it.

      2. If the response includes the "must-revalidate" cache-control
         directive, the cache MAY use that response in replying to a
         subsequent request. But if the response is stale, all caches
         MUST first revalidate it with the origin server, using the
         request-headers from the new request to allow the origin server
         to authenticate the new request.

      3. If the response includes the "public" cache-control directive,
         it MAY be returned in reply to any subsequent request.

10.4.2 401 Unauthorized

   The request requires user authentication. The response MUST include a
   WWW-Authenticate header field (section 14.47) containing a challenge
   applicable to the requested resource. The client MAY repeat the
   request with a suitable Authorization header field (section 14.8). If
   the request already included Authorization credentials, then the 401
   response indicates that authorization has been refused for those
   credentials. If the 401 response contains the same challenge as the
   prior response, and the user agent has already attempted
   authentication at least once, then the user SHOULD be presented the
   entity that was given in the response, since that entity might
   include relevant diagnostic information. HTTP access authentication
   is explained in "HTTP Authentication: Basic and Digest Access
   Authentication" [43].
   A URI Template is a sequence of characters that contains one or more
   embedded template variables Section 4.1.  A URI Template becomes a
   URI when the template variables are substituted with the template
   variables string values, see Section 4.2.  The following shows an
   example URI Template:

   http://example.com/widgets/widget_id

   If the value of the widget_id variable is "xyzzy", the resulting URI
   after substitution is:

   http://example.com/widgets/xyzzy
>>> import urllib
>>> urlread = lambda url: urllib.urlopen(url).read()
>>> import chardet
>>> chardet.detect(urlread("http://google.cn/"))
{'encoding': 'GB2312', 'confidence': 0.99}

>>> chardet.detect(urlread("http://yahoo.co.jp/"))
{'encoding': 'EUC-JP', 'confidence': 0.99}

>>> chardet.detect(urlread("http://amazon.co.jp/"))
{'encoding': 'SHIFT_JIS', 'confidence': 1}

>>> chardet.detect(urlread("http://pravda.ru/"))
{'encoding': 'windows-1251', 'confidence': 0.9355}

>>> chardet.detect(urlread("http://auction.co.kr/"))
{'encoding': 'EUC-KR', 'confidence': 0.99}

>>> chardet.detect(urlread("http://haaretz.co.il/"))
{'encoding': 'windows-1255', 'confidence': 0.99}

>>> chardet.detect(urlread("http://www.nectec.or.th/tindex.html"))
{'encoding': 'TIS-620', 'confidence': 0.7675}

>>> chardet.detect(urlread("http://feedparser.org/docs/"))
{'encoding': 'utf-8', 'confidence': 0.99}

14.17 Content-Type

   The Content-Type entity-header field indicates the media type of the
   entity-body sent to the recipient or, in the case of the HEAD method,
   the media type that would have been sent had the request been a GET.

       Content-Type   = "Content-Type" ":" media-type

   Media types are defined in section 3.7. An example of the field is

       Content-Type: text/html; charset=ISO-8859-4

   Further discussion of methods for identifying the media type of an
   entity is provided in section 7.2.1.
python manage.py validate pybookmarks
python manage.py sqlcustom 
pybookmarks
python manage.py sqlclear 
pybookmarks
DROP TABLE
python manage.py sqlindexes 
pybookmarks
CREATE INDEX
python manage.py sqlall 
pybookmarks
"django.contrib.admin"
INSTALLED_APPS
python manage.py syncdb
INSTALLED_APPS
mysite/urls.py
python manage.py runserver
bookmarks
Bookmark
pybookmarks/bookmarks/models.py
Admin
class Admin
models.DateTimeField
models.CharField
DateTimeField
env.sh
cherrypy/app.py
python app.py
python app.py &twill-sh -u http://localhost:8080/ simple-test.twill
nosetests -w demo1/
cherrypy/
.----------------------------------------------------------------------Ran 1 test in 2.069sOK
nosetests -w demo1/ -v
tests.test ... ok----------------------------------------------------------------------Ran 1 test in 2.069sOK
setup()
test()
teardown()
setup
app.py
pipe.stdout
setup
app.py
test
twill.execute_file
teardown
exit
setup
teardown
test2
url
pipe
url
import tests
url
Popen
/exit
teardown
setup()
wsgi_app = cherrypy.tree.mount(app.HelloWorld(), '/')twill.add_wsgi_intercept('localhost', 80, lambda: wsgi_app)
wsgi_app
wsgi_app
nosetests -w demo2/ -v
tests.test ... ok----------------------------------------------------------------------Ran 1 test in 0.827sOK
simple-test.twill
figleaf app.py
twill-sh -u http://localhost:8080/ simple-test.twill
app.py
figleaf2html
html/
html/app.py.html
page2
exit
def page2(self):
html/index.html
test()
test2()
page2
cherrypy/
rm .figleafnosetests -v --with-figleafsections -w demo3annotate-sections ./app.py
app.py
app.py
app.py.sections
app.py.sections
-- all coverage --| tests.test2| | tests.test

| | |        | #! /usr/bin/env python

| import cherrypy

|

| class HelloWorld(object):

|     def index(self):

+   |         return """<form method='POST' action='/form'>

|                   Type something: <input type='text' name='inp'>

|                   <input type='submit'>

|                   </form>"""

|     index.exposed = True

|

|     def form(self, inp=None, **kw):

+   |         return "You typed: \"%s\"" % (inp,)

|     form.exposed = True

|

|     def page2(self):

+     |         return "This is page2."

|     page2.exposed = True

|

|     def exit(self):

|         raise SystemExit

|     exit.exposed = True

|

| if __name__ == '__main__':

|     cherrypy.quickstart(HelloWorld())
tests.test
index()
form()
tests.test2
page2()
extend_with <module>
fuzzfill
extend_with randomformfuzzfill <form> 5 15 [ <alphabet> ]
HelloWorld
nosetests -w demo4/ -v
% nosetests -w demo4/ -v -stests.test ... 127.0.0.1 - - [15/Mar/2007:19:08:14] "GET / HTTP/1.1" 200 166 "" ""closing...

==> at http://localhost/

Imported extension module 'randomform'.

(at /Users/t/iorich-dev/talk-stuff/cherrypy/demo4/randomform.pyc)

127.0.0.1 - - [15/Mar/2007:19:08:14] "GET / HTTP/1.1

" 200 166 "" ""

closing...

==> at http://localhost/

fuzzfill: widget "inp" using value "0jX0vUXye0"

Note: submit is using submit button: name="None", value=""

127.0.0.1 - - [15/Mar/2007:19:08:14] "POST /form HTTP/1.1

" 200 23 "" ""

ok

closing...

You typed: "0jX0vUXye0"

[15/Mar/2007:19:08:14] ENGINE CherryPy shut down

----------------------------------------------------------------------

Ran 1 test in 0.617s

OK
TestDjangoPollSite.test
TestDjangoPollSite.setup()
test()
unittest
test*
TestDjangoPollSite
teardown()
test*
tests.setup()
tests.teardown()
setup()
teardown
run-recording-proxy
** scotch proxy server running on 127.0.0.1 port 8000 ...** RECORDING to filename 'recording.pickle'
django/mysite/
python manage.py runserver localhost:8001
Validating models...0 errors found.Django version 0.95.1, using settings 'mysite.settings'Development server is running at http://localhost:8001/

Quit the server with CONTROL-C.
REQUEST ==> http://localhost:8001/polls/++ RESPONSE: 200 OK++ (77 bytes of content returned)++ (response is text/html; charset=utf-8)

(# 1)
REQUEST ==> http://localhost:8001/polls/1/vote/(post form)choice:  "3"++ RESPONSE: 302 FOUND

++ (0 bytes of content returned)

++ (response is text/html; charset=utf-8)

(# 4)

REQUEST ==> http://localhost:8001/polls/1/results/
recording.pickle
translate-recording-to-twill recording.pickle
# record 0go http://localhost:8001/polls/# record 2#   referer = http://localhost:8001/polls/

go http://localhost:8001/polls/1/

# record 3

#   referer = http://localhost:8001/polls/1/

fv 1 choice '3'

submit
twill-sh
play-recorded-proxy recording.pickle
==> http://localhost:8001/polls/ ...... 200 OK (identical response)==> http://localhost:8001/polls/1 ...

... 301 MOVED PERMANENTLY (identical response)

==> http://localhost:8001/polls/1/ ...

... 200 OK (identical response)

==> http://localhost:8001/polls/1/vote/ ...

... 302 FOUND (identical response)

==> http://localhost:8001/polls/1/results/ ...

... 200 OK

++ OUTPUT DIFFERS

OLD OUTPUT:

====

<h1>what's up?</h1><ul>

<li>the blue sky -- 0 votes</li>

<li>not much -- 0 votes</li>

<li>pycon -- 2 votes</li>

</ul>

====

NEW OUTPUT:

====

<h1>what's up?</h1>

<ul>

<li>the blue sky -- 0 votes</li>

<li>not much -- 0 votes</li>

<li>pycon -- 5 votes</li>

</ul>

====

"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Méta

catégories

Archives

Blog Stats

Articles les plus consultés

Abonnez-vous à ce blog par e-mail.

Archive for the ‘Architecture logicielle’ Category

14.25 If-Modified-Since

14.8 Authorization

10.4.2 401 Unauthorized

14.17 Content-Type