Well, in the handshake the client receives only one packet from the server: SEQ=0 and ACK=1. With this information, the server tells the client 'I am waiting for a packet with SEQ=1 now'. You got this right.
Now, in the last part of the handshake the client sends a SEQ=1 and ACK=1, what basically means the same thing as from the server: 'I am waiting for your packet with SEQ=1 now'
But: After a TCP handshake, the client will usually not wait for this packet to be acked, but rather send the first data packets already (in fact, data may already be contained within the last packet of the handshake - I assume this is the case in your example, because the HTTP request has the same SEQ as the last handshake packet). So any next packet again has ACK=1. But why? It again says 'I am waiting for a packet with SEQ=1 from you'. And this completely makes sense: The last packet the client received from the server had SEQ=0 (in the handshake). Also keep in mind, that both client and server have independent SEQs. That means, that the client could send 100 packets. As long as the server did not send one, the client would still be waiting for ACK=1, because the last packet he received from the server hat SEQ=0
Another Edit:
To really understand what is going on, you might want to choose an example with different beginning SEQs (I already wrote it, SEQs of server and client are independent):
Client -> SYN, SEQ=100
Client <- SYN, ACK, SEQ=700, ACK=101 <- Server
Client -> ACK = 701, SEQ=101 [50 Bytes of data]
Client -> ACK = 701 [Again, didn't receive sth from server yet], SEQ = 151